All of lore.kernel.org
 help / color / mirror / Atom feed
From: "NeilBrown" <neilb@suse.de>
To: "Martin Wilck" <mwilck@suse.com>
Cc: "Peter Rajnoha" <prajnoha@redhat.com>,
	"Jes Sorensen" <jsorensen@fb.com>, "Coly Li" <colyli@suse.com>,
	lvm-devel@redhat.com, linux-raid@vger.kernel.org,
	dm-devel@redhat.com, "Heming Zhao" <heming.zhao@suse.com>
Subject: Re: [PATCH] udev-md-raid-assembly.rules: skip if DM_UDEV_DISABLE_OTHER_RULES_FLAG
Date: Wed, 23 Feb 2022 09:49:27 +1100	[thread overview]
Message-ID: <164557016782.28944.17731814770525408828@noble.neil.brown.name> (raw)
In-Reply-To: <4b61ca1eafb35e3fdfbc9bb260dc89d56d181499.camel@suse.com>

On Wed, 23 Feb 2022, Martin Wilck wrote:
> Neil,
> 
> On Tue, 2022-02-22 at 10:36 +1100, NeilBrown wrote:
> > 
> > > The flags that DM use for udev were introduced before systemd
> > > project
> > > even existed. We needed to introduce the
> > > DM_UDEV_DISABLE_OTHER_RULES_FLAG
> > > to have a possibility for all the "other" (non-dm) udev rules to
> > > check
> > > for if there's another subsystem stacking its own devices on top of
> > > DM
> > > ones.
> > 
> > If this is an established API that DM uses, then presumably it is
> > documented somewhere.  If a link to that documentation were provided,
> > it
> > would look a a whole lot less like a hack.
> 
> Peter has provided a link to libdevmapper.h in his previous post in
> this thread. Is this a request for me to include that link in the patch
> description?

If libdevmapper.h is the best documentation there is for this variable,
then hopefully you can see why it feels to an outsider like a hack.

It isn't even immediately clear that the text there is talking about
environment variables visible in udev.
If there is an expectation that tools outside of lvm2 will use these,
then they really should be documented properly.  SYSTEMD_READY is
documented in "man systemd.device".  How hard would it be to write a
"dm-udev" man page which explains all this.

But if libdevmapper.h is the best you have, then maybe it'll have to do.
It is up to Jes what he accepts of course.

Thanks,
NeilBrown

WARNING: multiple messages have this Message-ID (diff)
From: "NeilBrown" <neilb@suse.de>
To: "Martin Wilck" <mwilck@suse.com>
Cc: Jes Sorensen <jsorensen@fb.com>, Coly Li <colyli@suse.com>,
	Peter Rajnoha <prajnoha@redhat.com>,
	lvm-devel@redhat.com, linux-raid@vger.kernel.org,
	dm-devel@redhat.com, Heming Zhao <heming.zhao@suse.com>
Subject: Re: [dm-devel] [PATCH] udev-md-raid-assembly.rules: skip if DM_UDEV_DISABLE_OTHER_RULES_FLAG
Date: Wed, 23 Feb 2022 09:49:27 +1100	[thread overview]
Message-ID: <164557016782.28944.17731814770525408828@noble.neil.brown.name> (raw)
In-Reply-To: <4b61ca1eafb35e3fdfbc9bb260dc89d56d181499.camel@suse.com>

On Wed, 23 Feb 2022, Martin Wilck wrote:
> Neil,
> 
> On Tue, 2022-02-22 at 10:36 +1100, NeilBrown wrote:
> > 
> > > The flags that DM use for udev were introduced before systemd
> > > project
> > > even existed. We needed to introduce the
> > > DM_UDEV_DISABLE_OTHER_RULES_FLAG
> > > to have a possibility for all the "other" (non-dm) udev rules to
> > > check
> > > for if there's another subsystem stacking its own devices on top of
> > > DM
> > > ones.
> > 
> > If this is an established API that DM uses, then presumably it is
> > documented somewhere.  If a link to that documentation were provided,
> > it
> > would look a a whole lot less like a hack.
> 
> Peter has provided a link to libdevmapper.h in his previous post in
> this thread. Is this a request for me to include that link in the patch
> description?

If libdevmapper.h is the best documentation there is for this variable,
then hopefully you can see why it feels to an outsider like a hack.

It isn't even immediately clear that the text there is talking about
environment variables visible in udev.
If there is an expectation that tools outside of lvm2 will use these,
then they really should be documented properly.  SYSTEMD_READY is
documented in "man systemd.device".  How hard would it be to write a
"dm-udev" man page which explains all this.

But if libdevmapper.h is the best you have, then maybe it'll have to do.
It is up to Jes what he accepts of course.

Thanks,
NeilBrown

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

WARNING: multiple messages have this Message-ID (diff)
From: NeilBrown <neilb@suse.de>
To: lvm-devel@redhat.com
Subject: [PATCH] udev-md-raid-assembly.rules: skip if DM_UDEV_DISABLE_OTHER_RULES_FLAG
Date: Wed, 23 Feb 2022 09:49:27 +1100	[thread overview]
Message-ID: <164557016782.28944.17731814770525408828@noble.neil.brown.name> (raw)
In-Reply-To: <4b61ca1eafb35e3fdfbc9bb260dc89d56d181499.camel@suse.com>

On Wed, 23 Feb 2022, Martin Wilck wrote:
> Neil,
> 
> On Tue, 2022-02-22 at 10:36 +1100, NeilBrown wrote:
> > 
> > > The flags that DM use for udev were introduced before systemd
> > > project
> > > even existed. We needed to introduce the
> > > DM_UDEV_DISABLE_OTHER_RULES_FLAG
> > > to have a possibility for all the "other" (non-dm) udev rules to
> > > check
> > > for if there's another subsystem stacking its own devices on top of
> > > DM
> > > ones.
> > 
> > If this is an established API that DM uses, then presumably it is
> > documented somewhere.? If a link to that documentation were provided,
> > it
> > would look a a whole lot less like a hack.
> 
> Peter has provided a link to libdevmapper.h in his previous post in
> this thread. Is this a request for me to include that link in the patch
> description?

If libdevmapper.h is the best documentation there is for this variable,
then hopefully you can see why it feels to an outsider like a hack.

It isn't even immediately clear that the text there is talking about
environment variables visible in udev.
If there is an expectation that tools outside of lvm2 will use these,
then they really should be documented properly.  SYSTEMD_READY is
documented in "man systemd.device".  How hard would it be to write a
"dm-udev" man page which explains all this.

But if libdevmapper.h is the best you have, then maybe it'll have to do.
It is up to Jes what he accepts of course.

Thanks,
NeilBrown



  reply	other threads:[~2022-02-22 22:49 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-16 20:59 [PATCH] udev-md-raid-assembly.rules: skip if DM_UDEV_DISABLE_OTHER_RULES_FLAG mwilck
2022-02-16 20:59 ` mwilck
2022-02-16 20:59 ` [dm-devel] " mwilck
2022-02-16 22:09 ` NeilBrown
2022-02-16 22:09   ` NeilBrown
2022-02-16 22:09   ` [dm-devel] " NeilBrown
2022-02-17 10:58   ` Martin Wilck
2022-02-17 10:58     ` Martin Wilck
2022-02-17 10:58     ` [dm-devel] " Martin Wilck
2022-02-17 13:09     ` Peter Rajnoha
2022-02-17 13:09       ` Peter Rajnoha
2022-02-17 13:09       ` [dm-devel] " Peter Rajnoha
2022-02-21 23:36       ` NeilBrown
2022-02-21 23:36         ` NeilBrown
2022-02-21 23:36         ` [dm-devel] " NeilBrown
2022-02-22 13:54         ` Martin Wilck
2022-02-22 13:54           ` Martin Wilck
2022-02-22 13:54           ` [dm-devel] " Martin Wilck
2022-02-22 22:49           ` NeilBrown [this message]
2022-02-22 22:49             ` NeilBrown
2022-02-22 22:49             ` [dm-devel] " NeilBrown
2022-02-23  9:47             ` Martin Wilck
2022-02-23  9:47               ` Martin Wilck
2022-02-23  9:47               ` [dm-devel] " Martin Wilck
2022-02-28  8:48             ` Martin Wilck
2022-02-28  8:48               ` Martin Wilck
2022-02-28  8:48               ` [dm-devel] " Martin Wilck
2022-03-18 22:42               ` Martin Wilck
2022-03-18 22:42                 ` Martin Wilck
2022-03-18 22:42                 ` [dm-devel] " Martin Wilck
2022-02-28 15:28       ` Xiao Ni
2022-02-28 15:28         ` Xiao Ni
2022-02-28 15:28         ` Xiao Ni
2022-03-01  7:53         ` Peter Rajnoha
2022-03-01  7:53           ` Peter Rajnoha
2022-03-01  7:53           ` Peter Rajnoha
2022-02-17 13:20     ` Peter Rajnoha
2022-02-17 13:20       ` Peter Rajnoha
2022-02-17 13:20       ` [dm-devel] " Peter Rajnoha

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=164557016782.28944.17731814770525408828@noble.neil.brown.name \
    --to=neilb@suse.de \
    --cc=colyli@suse.com \
    --cc=dm-devel@redhat.com \
    --cc=heming.zhao@suse.com \
    --cc=jsorensen@fb.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=lvm-devel@redhat.com \
    --cc=mwilck@suse.com \
    --cc=prajnoha@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.