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
> all.
>
> 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.
>
> Opinions?

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.

Take care,

Bill