From: Mike Snitzer <snitzer@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: dm-devel@redhat.com, Zdenek Kabelac <zkabelac@redhat.com>,
Mikulas Patocka <mpatocka@redhat.com>,
Milan Broz <gmazyland@gmail.com>,
lvm-devel@redhat.com
Subject: Re: dm: introduce DM_GET_TARGET_VERSION
Date: Tue, 17 Sep 2019 09:39:03 -0400 [thread overview]
Message-ID: <20190917133903.GA3612@redhat.com> (raw)
In-Reply-To: <20190917063242.GA10776@infradead.org>
On Tue, Sep 17 2019 at 2:32am -0400,
Christoph Hellwig <hch@infradead.org> wrote:
> On Mon, Sep 16, 2019 at 08:16:41PM +0200, Milan Broz wrote:
> >
> > So the main idea behind this was just use already existing functionality
> > in kernel DM, and provide simple user-friendly way to detect some incompatibilites
> > more early. If detection is not there, we just fallback to the old way.
>
> Well, and the nice way to do that is to actually report the features,
> not some arbitrary version number. That is have a sysfs file (or
> ioctl for dm if that is the way to go) that reports a list of
> capabilities. Then userspace checks for that desired capability and
> only tries the feture if it is supported.
A target's version, while opaque and imperfect, has served DM pretty
well for a long time. Requires discipline when backporting changes but
stable@ version bumps generally don't occur because such a bump triggers
conflicts across the N stable@ kernels.
So I'm not opposed to fined grained reporting of target features. But
doing so can come later.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@redhat.com>
To: lvm-devel@redhat.com
Subject: dm: introduce DM_GET_TARGET_VERSION
Date: Tue, 17 Sep 2019 09:39:03 -0400 [thread overview]
Message-ID: <20190917133903.GA3612@redhat.com> (raw)
In-Reply-To: <20190917063242.GA10776@infradead.org>
On Tue, Sep 17 2019 at 2:32am -0400,
Christoph Hellwig <hch@infradead.org> wrote:
> On Mon, Sep 16, 2019 at 08:16:41PM +0200, Milan Broz wrote:
> >
> > So the main idea behind this was just use already existing functionality
> > in kernel DM, and provide simple user-friendly way to detect some incompatibilites
> > more early. If detection is not there, we just fallback to the old way.
>
> Well, and the nice way to do that is to actually report the features,
> not some arbitrary version number. That is have a sysfs file (or
> ioctl for dm if that is the way to go) that reports a list of
> capabilities. Then userspace checks for that desired capability and
> only tries the feture if it is supported.
A target's version, while opaque and imperfect, has served DM pretty
well for a long time. Requires discipline when backporting changes but
stable@ version bumps generally don't occur because such a bump triggers
conflicts across the N stable@ kernels.
So I'm not opposed to fined grained reporting of target features. But
doing so can come later.
next prev parent reply other threads:[~2019-09-17 13:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-16 9:55 [PATCH] dm: introduce DM_GET_TARGET_VERSION Mikulas Patocka
2019-09-16 9:55 ` Mikulas Patocka
2019-09-16 9:58 ` [PATCH] lvm: " Mikulas Patocka
2019-09-16 9:58 ` Mikulas Patocka
2019-09-16 14:21 ` dm: " Mike Snitzer
2019-09-16 14:21 ` Mike Snitzer
2019-09-16 18:01 ` [PATCH] " Christoph Hellwig
2019-09-16 18:01 ` [dm-devel] " Christoph Hellwig
2019-09-16 18:16 ` Milan Broz
2019-09-16 18:16 ` [dm-devel] " Milan Broz
2019-09-17 6:32 ` Christoph Hellwig
2019-09-17 6:32 ` [dm-devel] " Christoph Hellwig
2019-09-17 13:39 ` Mike Snitzer [this message]
2019-09-17 13:39 ` Mike Snitzer
2019-09-17 13:56 ` [PATCH] " John Dorminy
2019-09-17 13:56 ` [dm-devel] " John Dorminy
2019-09-17 14:06 ` Mike Snitzer
2019-09-17 14:06 ` Mike Snitzer
2019-09-17 15:38 ` Mikulas Patocka
2019-09-17 15:38 ` Mikulas Patocka
2019-09-17 15:44 ` John Dorminy
2019-09-17 15:44 ` John Dorminy
2019-09-17 20:08 ` Mike Snitzer
2019-09-17 20:08 ` Mike Snitzer
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=20190917133903.GA3612@redhat.com \
--to=snitzer@redhat.com \
--cc=dm-devel@redhat.com \
--cc=gmazyland@gmail.com \
--cc=hch@infradead.org \
--cc=lvm-devel@redhat.com \
--cc=mpatocka@redhat.com \
--cc=zkabelac@redhat.com \
/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.