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,.

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?

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-