From owner-cvs-all Tue Apr 25 17:55:39 2000 Delivered-To: cvs-all@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id DD90937B5E5; Tue, 25 Apr 2000 17:55:18 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id KAA38353; Wed, 26 Apr 2000 10:25:22 +0930 (CST) Date: Wed, 26 Apr 2000 10:25:22 +0930 From: Greg Lehey To: Robert Watson Cc: "David O'Brien" , Boris Popov , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: How about building modules along with the kernel? (was: cvs commit: src/sys/modules/syscons/fire fire_saver.c src/sys/modules/syscons/rain rain_saver.c src/sys/modules/syscons/warp warp_saver.c) Message-ID: <20000426102521.C38026@freebie.lemis.com> References: <20000426093809.R26934@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 25 April 2000 at 20:34:53 -0400, Robert Watson wrote: > On Wed, 26 Apr 2000, Greg Lehey wrote: > >> I mind. They *should* be built along with the kernel. Can we get a >> consensus that this needs to be done, and maybe even how? Back at the >> FreeBSDcon we discussed the matter, and the fact that the kernel >> probably needs to be in a subdirectory of root, along with the modules >> and possibly other information. Any comments? > > At the very least, they should not be built and installed with world -- > this can have some pretty bad side effects, especially in kernel hacking > environments. Yes, I can testify to that. > I could see a new (maybe already present) ``make buildmodules'' and > ``make installmodules'' target in /usr/src. Make in /usr/src builds userland. Modules are in kernel space, so they don't belong there. > I could also see the suggestion of building modules with a > particular kernel, although I'm not clear on the details and side > effects. I suppose to a large extent, this depends on how we see > kernels and modules being used. I see them as being used together. > We have thus far utterly failed to provide any kind of consistent > ABI for many of the common modules (nfs is a prime example) meaning > that in many cases, the modules are closely tied to the version of > the kernel selected. This makes debugging kernels with a changing > sys tree very difficult for a number of reasons. I look on modules as kernel extensions which share an intimate understanding of the kernel internal data structures. If we change the data structures, we will need to recompile the modules. If we leave the data structures alone and rebuild the kernel, we don't need to recompile the data structures. Maybe we should do something like this: 1. Decide which data structures modules are allowed to access (and be generous). 2. Maintain a data structure generation number. Every time one of the designated data structures changes, bump the number. Store the number both in the kernel and in each module. 3. When loading modules, compare the numbers. Refuse to load if they're different. This would also solve the "inexplicable" crashes people sometimes see. 4. Have two kernel build targets: "kernel" to build only the kernel, "all" to build the kernel and the modules. Comments? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message