[dm-devel] [git pull] device mapper fixes for 5.6-rc5

[Linus Torvalds]

On Wed, Mar 4, 2020, 13:23 Mike Snitzer <snitzer at redhat.com> 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

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20200304/28c330db/attachment.htm>