Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 03 Dec 2003 17:58:06 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        jhb@FreeBSD.org
Cc:        cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/i386/i386 machdep.c
Message-ID:  <20031203.175806.132781932.imp@bsdimp.com>
In-Reply-To: <XFMail.20031203162446.jhb@FreeBSD.org>
References:  <200312032112.hB3LC9GT079834@repoman.freebsd.org> <XFMail.20031203162446.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <XFMail.20031203162446.jhb@FreeBSD.org>
            John Baldwin <jhb@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031203.175806.132781932.imp>