Re: sio => uart: one port is gone

On Tuesday 16 September 2008 03:26:00 pm Peter Wemm wrote:
> On Mon, Sep 15, 2008 at 3:08 PM, John Baldwin <jhb_at_freebsd.org> wrote:
> > On Monday 15 September 2008 04:11:14 pm Marcel Moolenaar wrote:
> >>
> >> On Sep 15, 2008, at 1:02 PM, Andriy Gapon wrote:
> >>
> >> > --- a/sys/conf/files
> >> > +++ b/sys/conf/files
> >> > _at__at_ -1080,7 +1080,7 _at__at_ dev/twe/twe.c                 optional twe
> >> > dev/twe/twe_freebsd.c               optional twe
> >> > dev/tx/if_tx.c                      optional tx
> >> > dev/txp/if_txp.c            optional txp
> >> > -dev/uart/uart_bus_acpi.c   optional        uart acpi
> >> > +dev/uart/uart_bus_acpi.c   optional        uart
> >> > #dev/uart/uart_bus_cbus.c   optional        uart cbus
> >> > dev/uart/uart_bus_ebus.c    optional        uart ebus
> >> > dev/uart/uart_bus_isa.c             optional        uart isa
> >>
> >> This is exactly the thing we shouldn't be doing.
> >>
> >> You now compile the acpi bus attachment on platforms
> >> that don't even have acpi. This is not a fix, it's
> >> a breakage...
> >
> > You can change it in sys/conf/files.i386 instead.  (It's ok to have 
duplicate
> > lines across files*, the file gets compiled in if any one of the 
conditions
> > matches).
> 
> I agree.  If uart is representing itself as a sio replacement, then it
> needs to be a sio replacement.  And on i386, that presently means
> compiling the acpi attachment always.  ie: add a second
> "dev/uart/uart_bus_acpi.c optional uart" to files.i386.
> 
> On the other hand, we shouldn't be compiling acpi.ko as a module
> anyway.  It really is an integral part of any recent x86 machines.
> The PC2001 spec requires ACPI. You can't get a 'Designed for Windows
> XXX' logo unless you're compliant with >= PC2001 these days.  Having
> it as a module just adds memory overhead (admittedly small, but it is
> there).  Having a crash involving acpi means that you suddenly have
> more moving parts to keep track of for kgdb, and more things to go
> wrong in getting decent dump info.  (Granted, kgdb handles modules
> much better now, but it is still something to go wrong if the on-disk
> acpi.ko gets out of sync with the kernel.debug or the vmcore)
> 
> I prefer what happens on amd64.  It is compiled into the kernel, but
> on the rare occasion where it is a problem there is a hint to shut it
> down at boot.  i386 has the same hint already.  And if somebody really
> wants to build a custom kernel without it, that can be done too.  And
> they get the acpi bus attachments compiled out at the same time.
> 
> We're at least two full machine upgrade life cycles beyond the point
> where ACPI was effectively mandatory in PC's.  We really should be
> optimizing for the case where it is there rather than not.
> 
> As for soekris boxes without acpi - we already have compile-time
> options that are compelling for building a custom kernel for use on a
> soekris.  Booting GENERIC with embedded acpi is harmless though,
> except for the non-trivial kernel bloat in GENERIC.

I agree with just adding acpi to GENERIC on i386 and have that be the real 
solution.

-- 
John Baldwin