Date: Tue, 16 Sep 2008 15:53:01 -0400 From: John Baldwin <jhb@freebsd.org> To: "Peter Wemm" <peter@wemm.org> Cc: Marcel Moolenaar <xcllnt@mac.com>, Andriy Gapon <avg@icyb.net.ua>, freebsd-current@freebsd.org Subject: Re: sio => uart: one port is gone Message-ID: <200809161553.02028.jhb@freebsd.org> In-Reply-To: <e7db6d980809161226x48ce31e9ka71315129d617057@mail.gmail.com> References: <48CE59C2.9060307@icyb.net.ua> <200809151808.33400.jhb@freebsd.org> <e7db6d980809161226x48ce31e9ka71315129d617057@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 16 September 2008 03:26:00 pm Peter Wemm wrote: > On Mon, Sep 15, 2008 at 3:08 PM, John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200809161553.02028.jhb>