Dne 04. 03. 20 v 20:34 Linus Torvalds napsal(a):
On Wed, Mar 4, 2020, 13:23 Mike Snitzer <snitzer@xxxxxxxxxx
<mailto: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...
Hi
POV of lvm2 developer - there are 2 things to solve - 1st. is the introduction
of a new 'features'. The 2nd. is usability/stability of certain version of dm
targets - so when we later discover some combination of device stack are not
safe to use (can lead to significant lose of user's data) lvm2 adds check for
this.
The reason for complexity comes from fact - numerous distribution use version
of kernel X.Y.Z while they can have much new DM target version as it's much
more simple to backport new DM into older version.
Nothing is clearly 'perfect', there is no ideal solution to cover all
combination of all kernel backports - but current separate versioning stream
of DM targets added to kernel versioning, which i.e. lvm2 also is tracking,
adds more hints for safe decision (as the safety of user's data is the most
important here) and allows various distributions to 'somehow reasonably'
handle backporting of bugfixes.
So if there would be 'feature flag' list provided by DM target - there still
should be visible which version of implemented flag is that - as when the new
feature is added - it's not always 'perfect' - sometimes we discover q bug
quite late in the process of new feature introduction - so the plain fact
'featureXYZ' is present unfortunately doesn't always mean it's usable.
Sometimes even 'fixing' one bug may introduce a new problem we discover again
later (testing combinations of device stacks is really madness of its own...)
Zdenek
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
