Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Apr 2000 22:40:23 -0400 (EDT)
From:      Chuck Robey <chuckr@picnic.mat.net>
To:        Greg Lehey <grog@lemis.com>
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:  <Pine.BSF.4.21.0004252235470.331-100000@picnic.mat.net>
In-Reply-To: <20000426102521.C38026@freebie.lemis.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0004252235470.331-100000>