From owner-cvs-all@FreeBSD.ORG Wed Dec 3 19:55:42 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 3A0A516A4CF for ; Wed, 3 Dec 2003 19:55:42 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id E6BC943FBD for ; Wed, 3 Dec 2003 19:55:38 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 21998 invoked by uid 1000); 4 Dec 2003 03:55:40 -0000 Date: Wed, 3 Dec 2003 19:55:40 -0800 (PST) From: Nate Lawson To: John Baldwin In-Reply-To: Message-ID: <20031203195324.P21901@root.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 03:55:42 -0000 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