sio => uart: one port is gone

Marcel Moolenaar xcllnt at mac.com
Mon Sep 15 23:05:10 UTC 2008


On Sep 15, 2008, at 3:21 PM, Brooks Davis wrote:

> On Mon, Sep 15, 2008 at 06:07:45PM -0400, John Baldwin wrote:
>> On Monday 15 September 2008 04:13:10 pm Marcel Moolenaar wrote:
>>>
>>> On Sep 15, 2008, at 12:22 PM, John Baldwin wrote:
>>>
>>>> On Monday 15 September 2008 12:55:33 pm Marcel Moolenaar wrote:
>>>>>
>>>>> On Sep 15, 2008, at 9:47 AM, Andriy Gapon wrote:
>>>>>
>>>>>> on 15/09/2008 19:41 Marcel Moolenaar said the following:
>>>>>>> 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...
>>>>>>
>>>>>> I understand the logic, but OTOH uart can work without acpi  
>>>>>> too, so
>>>>>> it's not a strict dependency.
>>>>>
>>>>> Well, yes. That's what's causing your "problem". You compile a
>>>>> kernel without acpi but with uart. As such, uart will be built
>>>>> without acpi support. uart does indeed work without acpi.
>>>>>
>>>>> The problem is that people then load the acpi module at runtime
>>>>> and expect uart to work with acpi. That's not going to fly. If
>>>>> one builds uart as a module, all possible support is included
>>>>> and it works as expected.
>>>>>
>>>>>> Also, this (acpi dependency) doesn't seem to be documented.
>>>>>
>>>>> It's standard behaviour.
>>>>
>>>> The problem is that right now we ship with acpi.ko as a module by
>>>> default and
>>>> have the loader auto-load acpi.ko IFF the machine supports ACPI.
>>>
>>> Well, don't do that then. Just have the device probe check if acpi  
>>> is
>>> supported and attach if yes.
>>
>> It does that, the loader stuff is from someone trying to be fancy  
>> and save the
>> memory of not having acpi.ko around if the system doesn't support  
>> it.  This
>> may in fact be dubious. :)
>
> While acpi.ko is a beast (about .5MB) we're really only talking  
> about savings
> in the case when people are using GENERIC so it seems highly dubious.

I tend to agree. If we didn't had the side-effects, then
it's neat little thing.

It would be interesting to experiment with how we can
control code/data placement, so that we can bundle code
or data in a way that allows us to re-use memory when
the code or data is not needed (anymore). Such as kernel
initialization code, driver code, firmware data, etc...

-- 
Marcel Moolenaar
xcllnt at mac.com





More information about the freebsd-current mailing list