> Here is the patch I made according to previous discussion. Currently
> it refuses to load the LKM if any of DIAGNOSTIC, DEBUG, LOCKDEBUG
> and MULTIPROCESSOR options are different, as well as LKM_VERSION
> and __NetBSD_Version__. I changed some interface, taking advantage
> of the necessary LKM_VERSION bump. The string 'evnronment depends'
> are not imlemented yet, so it's not possible for the LKM to say
> it depends on some of the options only.
> 

About versioning: I think it would be neat if the linker should read
a capability string telling which capabilities a certain module need,
and then do what it can about it.  This is especially interesting if
the module is attached somewhere in the autoconf tree (about which I
plan to come up with a proposal later). 

Example: All LKM's have a capability string something like:

#ifdef LKM
const char *lkm_caps = "\01FOO\02BAR";
#endif

which tells the linker what it needs.  This means that if the kernel
stuff associated with FOO have it's version wrapped to 2, the linker
can search for FOO_compat01 instead. 

This is not workable as the LKM stuff is today, but if a LKM version
system is implemented it would be nice if it is  forward-compatible.
The above stuff could for example be wrapped in some nice cpp macro.

Also, a LKM interface description with "recommended" in-kernel calls 
to use should also be specified. Then it would be very useful to the
"third-party" module writers that is around.

-- Ragge