From owner-cvs-src@FreeBSD.ORG Thu Oct 30 11:39:14 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BAE616A4CE for ; Thu, 30 Oct 2003 11:39:14 -0800 (PST) Received: from mail.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2972243FE5 for ; Thu, 30 Oct 2003 11:39:11 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 18460 invoked from network); 30 Oct 2003 19:39:10 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 30 Oct 2003 19:39:10 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h9UJd6ce039555; Thu, 30 Oct 2003 14:39:06 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031030122318.J11750@pooker.samsco.home> Date: Thu, 30 Oct 2003 14:39:06 -0500 (EST) From: John Baldwin To: Scott Long X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: "M. Warner Losh" cc: cvs-all@FreeBSD.org cc: nate@root.org Subject: Re: cvs commit: src/sys/conf options src/sys/i386/acpica Makefile acpi_wakecode.S src/sys/i386/conf NOTES X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 19:39:14 -0000 On 30-Oct-2003 Scott Long wrote: > On Thu, 30 Oct 2003, M. Warner Losh wrote: >> In message: <20031030102144.L89089@root.org> >> Nate Lawson writes: >> : On Wed, 29 Oct 2003, M. Warner Losh wrote: >> : > In message: <20031029.232311.115991039.imp@bsdimp.com> >> : > M. Warner Losh writes: >> : > : The "general silliness of compiling SMP for all modules" was a design >> : > : decision for SMPng made a long time ago. That's why there's no longer >> : > : a SMP kernel option. >> : > >> : > Actually, I'm smoking crack here. Forget I said it. >> : > >> : > We do, however, don't use the lock prefix on UP kernels. Instead, >> : > modules call the atomic functions, rather than inlining them. >> : >> : Whatever you smoke, the bounty is now up to $40, thanks to another donor. >> : Let's see some code! >> >> I'll clean up what I have and commit it. >> >> Warner >> >> > > Please, if you're going to do this, do it 100%. Peter had some > interesting ideas with unifying the building process of the kernel > and modules and making the two basically indistinguishable. This > would likely get rid of the #ifdef KLD_MODULE hacks running around > too. KLD_MODULE needs to stay in some form. The problem is how does a 3rd party build a kernel module that works on all kernels (other than the PAE case, which is a very special case IMO) Basically, there are two different classes of modules that we need (I think): 1) Modules optimized for a given kernel config. These modules should be built during a kernel build, should _not_ have KLD_MODULE defined but should have access to all the normal config opt_foo headers. They should also be built in the current directory of the kernel. A module shouldn't be built if it is already compiled into the kernel. In fact, the kernel config should actually list the modules with something like 'module wi' or some such. - The duplication of metadat between module Makefiles and sys/conf/files needs to stop. I would prefer that we go with the sys/conf/files type approach, but it might need some tweaking to get right. 2) Modules that should "run everywhere". 3rd party vendors need this type of module. This module should be built with KLD_MODULE defined. In fact, assuming you get 1) to actually work correctly, you could implement this by using a kernel config like so: # config for module 'foo' options KLD_MODULE module foo Possibly with an optional keyword to disable kernel building. Though that could be implemented by having config assume that it is only compiling modules if there is no 'ident' keyword. Howver, we need a plan with a known end destination that can be worked towards, we shouldn't just blindly stumble around without a clear direction of what we want out of our kernel modules system. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/