cvs commit: src/sys/i386/i386 machdep.c
M. Warner Losh
imp at bsdimp.com
Wed Dec 3 16:58:35 PST 2003
In message: <XFMail.20031203162446.jhb at FreeBSD.org>
John Baldwin <jhb at FreeBSD.org> writes:
:
: On 03-Dec-2003 John Baldwin wrote:
: > jhb 2003/12/03 13:12:09 PST
: >
: > FreeBSD src repository
: >
: > 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'm not sure I follow what you are saying here. You need to have
something to resolve the symbols that madt provides.
As to the bus attachments, busses are supposed to provide a kobj
interface such that no symbols are exported directly to the bus. eisa
does, however, violate this.
Warner
More information about the cvs-src
mailing list