From: Mike Snitzer <snitzer@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: dm-devel@redhat.com, linux-block <linux-block@vger.kernel.org>,
Alasdair G Kergon <agk@redhat.com>, Hou Tao <houtao1@huawei.com>,
Mikulas Patocka <mpatocka@redhat.com>,
Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
Theodore Ts'o <tytso@mit.edu>
Subject: Re: [git pull] device mapper fixes for 5.6-rc5
Date: Wed, 4 Mar 2020 14:23:35 -0500 [thread overview]
Message-ID: <20200304192335.GA24296@redhat.com> (raw)
In-Reply-To: <CAHk-=wgP=q648JXn8Hd9q7DuNaOEpLmxQp2W3RO3vkaD2CS_9g@mail.gmail.com>
On Wed, Mar 04 2020 at 2:06pm -0500,
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, Mar 4, 2020 at 9:03 AM Mike Snitzer <snitzer@redhat.com> wrote:
> >
> > - Bump the minor version for DM core and all target versions that have
> > seen interface changes or important fixes during the 5.6 cycle.
>
> Can we please remove these pointless version markers entirely?
>
> They make no sense. The kernel doesn't allow backwards incompatible
> changes anyway, so the whole point of using some kind of interface
> versioning is entirely bogus.
>
> The way you test if a new feature exists or not is to just use it, and
> if you're running on an old kernel that doesn't support that
> operation, then it should return an error.
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.
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.
I'll think further about this issue and consult with userspace
developers and see what we might do.
Thanks (for the needed kick in the ass).
Mike
next prev parent reply other threads:[~2020-03-04 19:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-04 15:02 [git pull] device mapper fixes for 5.6-rc5 Mike Snitzer
2020-03-04 19:06 ` Linus Torvalds
2020-03-04 19:23 ` Mike Snitzer [this message]
2020-03-04 19:34 ` Linus Torvalds
2020-03-05 9:44 ` [dm-devel] " Zdenek Kabelac
2020-03-04 20:02 ` Theodore Y. Ts'o
2020-03-04 19:15 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200304192335.GA24296@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=houtao1@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=shinichiro.kawasaki@wdc.com \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.