Nathan J. Williams wrote:
> I think that's optimistic. We aren't so agressive with kernel version
> bumps that every possible LKM incompatibility is noted there. The
> conditions you list are probably necessary for compatibility, but they
> are not sufficent. To put it another way, we should remain aware that
> no mechanism can prevent all LKM incompatibilites.

I'm aware that some changes might still fall through cracks.
I aim basically to catch common issue that you update kernel, don't
update LKMs, and get panic once you'd use the LKM code.
 
> This is an area where pretty much every other Unix-like OS in the
> world has more experience than we do. We should be able to learn from
> their efforts, rather than blindly reinventing versioning
> schemes. What does the prior art look like?

Seems that Linux only checks kernel version. I don't see anything
else in the module interface besides that (looked into <linux/module.h>).
My guess is they define their interfaces so that kernel options
don't change structure sizes - or don't have kernel-wide options :)

FreeBSD doesn't seem to check any kmod version. Some structures
are versioned, but I can't see anything else. Looked into
<sys/module.h>, kern/kern_linker.c, kern/kern_module.c.

Bill Studenmund wrote:
> > 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.

I'd like to keep this simple, so being based on kernel version looks
like the most likely to work for everyone. It's not always very simple
to find out which particular classes of modules are affected
by changed kernel ABI.

Some provision might be added for stable branches, since
kernel ABI doesn't normally change on stable branch.

Andrew Brown wrote:
> USE_TOPDOWN_VM might be another one.  i'm not sure...

Yes, if it changes structures exported to outside uvm.

> as long as the code i have in one module
> ...
> still works, i don't mind :)

Yes, it will - this change only affect whether or not you'd be able
to load the module, not any interface.

My intent is to structure the version in such a way as to catch
most fatal ABI mismatches. Currently, we don't do any check of LKM
version, so any improvement would be nice. The versioning scheme
might change any time; it would just mean that LKMs done for previous
releases don't work in then-current release, which is a axiom
anyway.

I'll try to evaluate the proposed LKM versioning scheme
and post diff later.

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.''     -=-