On Wed, Mar 4, 2020, 13:23 Mike Snitzer <snitzer@xxxxxxxxxx> wrote:
These versions are for userspace's benefit (be it lvm2, cryptsetup,
multipath-tools, etc). But yes, these versions are bogus even for
that -- primarily because it requires userspace to know when a
particular feature/fix it cares about was introduced. In addition: if
fixes, that also bump version, are marked for stable@ then we're quickly
in versioning hell -- which is why I always try to decouple version
bumps from fixes.
Yeah, I think the drm people used to have a version number too, and it's not just fixes getting backported to stable - it's distro kernels taking changes for new hardware without taking other parts etc.
So the versioning ends up not ever working reliably anyway - the same way that you can't use the kernel version number to determine what system calls are available.
So versions can not ever be anything more than informational, and it's usually just very confusing to have multiple different version numbers (ie "I'm running kernel v5.4, and my driver abc version is 1.4.2a" is *not* in the least helpful).
Others have suggested setting feature flags. I expect you'd hate those
too. I suspect I quickly would too given flag bits are finite and
really tedious to deal with.
It also leads to some people then thinking it's ok to remove features (perhaps to reimplement them differently) if they only clear the feature bit.
And no, it's not how kernel interfaces work. We keep the interfaces even if the internals change.
So I've been suggesting that people just freeze the version, or remove the interface entirely is possible.
Because otherwise it's just a source of problems, where user space might refuse to do something that the kernel supports because of some silly version check...
Linus
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
