Re: sio => uart: one port is gone

From: Marcel Moolenaar <xcllnt_at_mac.com>
Date: Mon, 15 Sep 2008 09:41:32 -0700
On Sep 15, 2008, at 9:28 AM, Andriy Gapon wrote:

> on 15/09/2008 18:58 Marcel Moolenaar said the following:
>> On Sep 15, 2008, at 5:49 AM, Andriy Gapon wrote:
>>>
>>> This is a fairly standard and old machine with 2 COM ports.
>>> Recently (last Friday) I decided to update my RELENG_7 system and  
>>> also to transition from sio to uart.
>>>
>>> This what I had before the upgrade:
>>> kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4  
>>> flags 0x10 on acpi0
>>> kernel: sio0: type 16550A
>>> kernel: sio0: [FILTER]
>>> kernel: sio1: <16550A-compatible COM port> port 0x2e8-0x2ef irq 3  
>>> on acpi0
>>> kernel: sio1: type 16550A
>>> kernel: sio1: [FILTER]
>>>
>>> This is what I have now:
>>> uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10  
>>> on isa0
>>> uart0: [FILTER]
>>>
>>> This is what I have in device.hints for uart:
>>> hint.uart.0.at="isa"
>>> hint.uart.0.port="0x3F8"
>>> hint.uart.0.flags="0x10"
>>> hint.uart.0.irq="4"
>>> hint.uart.1.at="isa"
>>> hint.uart.1.port="0x2F8"
>>> hint.uart.1.irq="3"
>>> hint.uart.2.at="isa"
>>>
>>> Precisely the same hints (s/uart/sio/) I had for sio.
>> The hints are bogus. As you can see, sio(4) attached to acpi(4),
>> whereas uart(4) attaches to isa(4).
>
> Yes and yes.
>
>> Don't compile ACPI as a kernel module and all is fine.
>
> What is the alternative?
> Building it into a kernel?

Yes.

> Is this maybe too much of a requirement?

It's how our modules work. You can safely compile leaf drivers
as modules (leaf drivers are drivers that have no other drivers
depending on it), but we don't deal well with non-leaf drivers.
acpi(4) is a non-leaf driver, with sio(4) and uart(4) depending
on it. If you compile acpi(4) as a module, you should do the
same for sio(4), uart(4), etc. We don't enforce that, which is
the problem.

sio(4) added a kluge to work around the design/implementation
flaw, whereas uart(4) does not. The reason uart(4) does not is
that you don't want to compile-in code that you don't need.
It bloats the kernel and we need to keep our embedded platforms
in mind.

So, if you compile acpi(4) as a module, you must compile all
it's depending drivers as modules as well. Or you compile acpi
into the kernel...

> From /sys/i386/conf/NOTES (RELENG_7):
> # Note that building ACPI into the kernel is deprecated; the module is
> # normally loaded automatically by the loader.

Just another bogus note. Compiling ACPI into the kernel is
not deprecated, because it's required for at least ia64 and
I think for amd64 as well.

-- 
Marcel Moolenaar
xcllnt_at_mac.com
Received on Mon Sep 15 2008 - 14:41:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:35 UTC