Subject: Re: LKM versioning
To: Jaromir Dolecek <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 04/07/2003 10:30:42
On Mon, 7 Apr 2003, Jaromir Dolecek wrote:
> I've been bitten by obsolete LKM causing kernel panic once too
> often today, so I'm thinking how we could solve this once and for
> We now have LKM_VERSION, which is built into any LKM and
> checked when LKM is loaded. When this number is different
> to kernel LKM version, the LKM is refused and not glued into kernel.
> However, this number is never changed, and manually changing it
> inconvenient. It basically needs to be bumped any time kernel
> version is bumped,.
Not necessarily. _A_ version number needs bumping, but not necessarily
this one. It could well be we need more than one.
> LKM is only fully compatible with running kernel if:
> * the running kernel version matches with what LKM was built against
> * DIAGNOSTIC, DEBUG, MULTIPROCESSOR have same setting; possibly
> also LOCKDEBUG
> * maybe something else I forgot
> The second item is since some structures have different size
> when either of these is set.
> To automatically handle this, I'd propose to define LKM_VERSION
> some way from kernel version and those options.
> Observing the lowest two digits of __NetBSD_Version__ are unused,
> we could build LKM_VERSION like this:
> #define LKM_VERSION \
> (__NetBSD_Version__ + (DIAGNOSTIC*1) + (DEBUG*2) + (MULTIPROCESSOR*4) \
> + (LOCKDEBUG*8))
> This should help make LKMs a bit less fragile.
> When the LKM would be refused, kernel would print some diagnostics
> to help find out which options were used to build the kernel
> and the LKM.
I like what you're doing, but I think this won't scale. I think a better
thing is to have an LKM version (to version the whole interface), the
kernel version, and a string of "attributes," which would be things like
DEBUG, etc. that indicate overall attributes that have to match.
It also would help if we take Nathan & David's advice and just rip off an
existing set of module interfaces, and to start writing our kernel with
DDIs & such in mind.