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

[Nate Lawson]

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?

-Nate