Date: Wed, 26 Apr 2000 10:25:22 +0930 From: Greg Lehey <grog@lemis.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: "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: <20000426102521.C38026@freebie.lemis.com> In-Reply-To: <Pine.NEB.3.96L.1000425203025.29138A-100000@fledge.watson.org> References: <20000426093809.R26934@freebie.lemis.com> <Pine.NEB.3.96L.1000425203025.29138A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000426102521.C38026>