On Tue, 15 Apr 2003, Jaromir Dolecek wrote:

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

But that's not enough. While I agree it's a bit much to tell you to fix it
all, I think it makes more sense to choose something that will leave room
for other version schemes later.

> > 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 :)

Well, that doesn't mean we can't do stuff better. :-) There is a whole
versioning thing so that older modules will still work (mainly device
drivers). It didn't work for me, but it must work for some folks.

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

But I think it's evident we need more than just simple. While I don't mind
having the kernel version be in there - it certainly should - I think we
already know we need more, but we aren't sure what.

I'd say we need:

a) LKM version (so we can pull the full rug out from under us in the
	future)

b) Kernel version

c) A string of add-on defines.

I think for now it's fine for all three to have to match exactly. i.e. the
string has to be in alphabetical order, and use some consistent separator.

That way you leave a way to be flexable about stuff, yet you don't have to
invent it all now. :-)

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

Please at least keep the LKM version info format (the LKM version now)
separate from what ever else is there. That way we can change it easily
later if we choose to. Please also don't use the adding-constants-to-
the-kernel-version-number scheme, as it won't scale.

Take care,

Bill