From owner-cvs-all Tue Apr 25 19:40:49 2000 Delivered-To: cvs-all@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id A39E037B724; Tue, 25 Apr 2000 19:40:41 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id WAA13962; Tue, 25 Apr 2000 22:40:23 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Tue, 25 Apr 2000 22:40:23 -0400 (EDT) From: Chuck Robey To: Greg Lehey Cc: Robert Watson , "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) In-Reply-To: <20000426102521.C38026@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 Apr 2000, Greg Lehey wrote: > > 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? Just one, Greg. I fully applaud the aim of this (heck, I thought I was being original when I came up with the idea 2 years ago ... I know better now) but it seems like there's 2 jobs, even though one is easier than the other. What about changing the build, first, so that the modules are built and installed with the kernel, then AFTER that, worry about the versioning problem? That way, if we end up arguing about the versioning scheme for 2 more years, at least *something* comes of this, something I think we all agree is needed? If you want, I'd do this myself this weekend. I don't think the makefile part is all that difficult. ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@picnic.mat.net | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message