On Sun, 24 Aug 2003, Jaromir Dolecek wrote:

> this is the final version of basic LKM versioning code. The idea
> is to detect some cases of incompatibility between to-be-loaded
> LKM and kernel, eliminating the old problem with stale LKMs
> causing crashes.

Cool.

> The change makes kernel to refuse to load LKM compiled
> for different kernel version, or with different setting
> of DIAGNOSTIC, DEBUG, LOCKDEBUG and MULTIPROCESSOR flags.
> The version checks are extensible, so it's possible
> to check e.g. more options or transparently allow
> kernel version mismatch for some cases (would be useful
> on stable branches, where the kernel structures don't change).

My only concern is the use of _LKM_ENV_VERSION. I'd rather we just use a
string-based matching. i.e. if you had DEBUG and MULTIPROCESSOR, the
string'd be something like, "DEBUG,MULTIPROCESSOR". While I notice that
you are labeling bit positions (I think that's what the other string's
doing), we still run into issues if we ever define more than 32 options we
track.

Also, is there a way to force an LKM load? i.e. tell the kernel, "Yes, I
realize you might not like this, please load it anyway." ?? That way we
can eventually move more complicated policy to userland.

> This version, countrary to previous version posted here,
> retains source-code compatibility with older LKM interface,
> so LKM modules won't normally need any changes to be compilable
> under new world. They will need to be recompiled, though.
>
> If there won't be any serious objections to this, I'd commit
> this within couple of days.

Thank you for working on this. I think it's an important step. My only
concern is the one above. :-)

Take care,

Bill