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

[Zdenek Kabelac <zkabelac@redhat.com>]

Dne 04. 03. 20 v 20:34 Linus Torvalds napsal(a):
> 
> 
> On Wed, Mar 4, 2020, 13:23 Mike Snitzer <snitzer@redhat.com 
> <mailto:snitzer@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...

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