Re: sio => uart: one port is gone

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.

-- 
Peter Wemm - peter_at_wemm.org; peter_at_FreeBSD.org; peter_at_yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell