sio => uart: one port is gone
John Baldwin
jhb at freebsd.org
Tue Sep 16 20:19:37 UTC 2008
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
> >> > @@ -1080,7 +1080,7 @@ 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
More information about the freebsd-current
mailing list