cvs commit: src/sys/i386/i386 machdep.c

[John Baldwin]

On 04-Dec-2003 Nate Lawson wrote:
> On Wed, 3 Dec 2003, John Baldwin wrote:
>> On 03-Dec-2003 John Baldwin wrote:
>> >   Modified files:
>> >     sys/i386/i386        machdep.c
>> >   Log:
>> >   - Remove the hack to prevent the acpi module from loading.
>> >   - Add a really, really, nasty hack to provide stub versions of all of
>> >     the 'device apic' functions used by the ACPI MADT APIC enumerator if
>> >     'device apic' is not compiled into the kernel.  This is gross but is
>> >     the best we can do with the current kernel linker implementation.
>> >
>> >   Approved by:    re (scottl / blanket)
>>
>> Ideally, acpi.ko would contain two modules: 1 main acpi.kld module
>> that was required and one optional madt.kld module that just contained
>> madt.o and was optional.  Then loading the module would succeed so
>> long as the required 'acpi' module linked but if the optional 'madt'
>> module failed to link, it would just be tossed.  We don't really seem
>> to be setup to do such things right now though.  A more feasible model
>> might be an acpi.a that contains acpi.ko and madt.ko and allow the
>> kernel linker to handle foo.a by requiring the first .ko in the archive
>> to link and having any additional .ko's be optional.  This would work
>> both for the acpi.ko/madt.ko case as well as bus attachments for device
>> drivers such as a sym.a with sym.ko/sym_pci.ko/sym_cbus.ko, etc.
> 
> I think this could be achieved by simply unloading a module (and any
> modules that depend on it) if it fails to link instead of panicing.  The
> normal MODULE_DEPEND would still deal with the ordering of modules.
> Isn't it that simple?

Then the acpi.ko module would never load on a UP kernel.
The problem is that madt.ko needs symbols from both ACPI and the
device apic code.  However, both acpi.ko and madt.ko are logical
pieces of acpi, as would be foo.ko and foo_pci.ko logical pieces
of the foo driver.  So, I should be able to say 'set acpi_load=YES'
in the loader and end up with the loader trying to load both acpi.ko
and madt.ko but having things work fine and if madt.ko fails to link
and just throwing madt.ko away in that case.  If you create an acpi.a
and have the loader load a foo.a file if foo.ko doesn't exist then
that gets you a large part of the way there.  Then you just need a
way to have madt.ko fail to link w/o an error and w/o having acpi.ko
unloaded as well.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/