Subject: Re: LKM versioning patch
To: Jaromir Dolecek <email@example.com>
From: None <firstname.lastname@example.org>
Date: 05/03/2003 12:02:40
> 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:
const char *lkm_caps = "\01FOO\02BAR";
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.