Date: Wed, 26 Apr 2000 12:47:29 +0930 From: Greg Lehey <grog@lemis.com> To: Chuck Robey <chuckr@picnic.mat.net> Cc: Robert Watson <rwatson@FreeBSD.org>, "David O'Brien" <obrien@FreeBSD.org>, Boris Popov <bp@FreeBSD.org>, 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: <20000426124729.D40207@freebie.lemis.com> In-Reply-To: <Pine.BSF.4.21.0004252235470.331-100000@picnic.mat.net> References: <20000426102521.C38026@freebie.lemis.com> <Pine.BSF.4.21.0004252235470.331-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 25 April 2000 at 22:40:23 -0400, Chuck Robey wrote:
> 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?
Sure, the build is the easier part. In fact, looking back, I see I've
forgotten a point:
X. Install the kernel and its modules in a subdirectory. I'd suggest
we call the subdirectory /kernel/, so we can rename the
subdirectories on install the way we currently rename the kernel
itself. What do we call the kernel? How about /kernel/FreeBSD?
> 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?
Well, let's see if we all agree :-)
> If you want, I'd do this myself this weekend. I don't think the
> makefile part is all that difficult.
Agreed. I'd certainly welcome this.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000426124729.D40207>