From owner-cvs-all@FreeBSD.ORG Wed Dec 3 16:58:35 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D5BC16A4CE; Wed, 3 Dec 2003 16:58:35 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F85D43FB1; Wed, 3 Dec 2003 16:58:32 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id hB40wVgt048412; Wed, 3 Dec 2003 17:58:31 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 03 Dec 2003 17:58:06 -0700 (MST) Message-Id: <20031203.175806.132781932.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: References: <200312032112.hB3LC9GT079834@repoman.freebsd.org> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 machdep.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2003 00:58:35 -0000 In message: John Baldwin 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