linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@suse.com>
To: Peter Rajnoha <prajnoha@redhat.com>,
	Zdenek Kabelac <zkabelac@redhat.com>,
	 Benjamin Marzinski <bmarzins@redhat.com>,
	David Teigland <teigland@redhat.com>
Cc: linux-lvm@lists.linux.dev, dm-devel@lists.linux.dev,
	Hannes Reinecke <hare@suse.de>
Subject: Re: [RFC PATCH 7/7] 10-dm.rules: bump DM_UDEV_RULES_VSN to 3
Date: Mon, 04 Mar 2024 17:46:17 +0100	[thread overview]
Message-ID: <1bfb001084b17ab60c57f4819711c7d91c461536.camel@suse.com> (raw)
In-Reply-To: <dfb7c85c-81fb-493b-a897-dae355d22d82@redhat.com>

On Mon, 2024-03-04 at 12:09 +0100, Peter Rajnoha wrote:
> On 3/1/24 23:40, Martin Wilck wrote:
> > Bump the rules version in order to indicate that upper level rules
> > should consume DM_UDEV_DISABLE_OTHER_RULES_FLAG rather than
> > DM_NOSCAN
> > and DM_SUSPENDED.
> > 
> > Signed-off-by: Martin Wilck <mwilck@suse.com>
> > ---
> >  udev/10-dm.rules.in | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/udev/10-dm.rules.in b/udev/10-dm.rules.in
> > index d30f663..21bbcb0 100644
> > --- a/udev/10-dm.rules.in
> > +++ b/udev/10-dm.rules.in
> > @@ -136,7 +136,9 @@ LABEL="dm_suspended_set"
> >  # possible future changes.
> >  # VSN 1 - original rules
> >  # VSN 2 - add support for synthesized events
> > -ENV{DM_UDEV_RULES_VSN}="2"
> > +# VSN 3 - use DM_UDEV_DISABLE_OTHER_RULES_FLAG as the only "API"
> > +#         to be consumed by non-dm rules.
> > +ENV{DM_UDEV_RULES_VSN}="3"
> >  
> >  ENV{DM_UDEV_DISABLE_DM_RULES_FLAG}!="1", ENV{DM_NAME}=="?*",
> > SYMLINK+="(DM_DIR)/$env{DM_NAME}"
> >  
> 
> One thing that comes to my mind here is cooperation between the rules
> from initrd/initramfs and rootfs - the initrd/initramfs can have
> different versions of the rules installed.

Yes, that's a source of pain. Are there current initramfs tools that
user DM_UDEV_RULES_VSN!=2? I think "2" should be the standard today,
given that it has existed since 2009. dracut just installs the upstream
rules it finds, at least for dm, AFAICT.

I've reviewed other rule sets I'm aware of, and the only one in which I
needed to check DM_UDEV_RULES_VSN was 11-dm-mpath.rules. I didn't have
a close look at the rule sets that dracut ships yet, let alone other
tools for initramfs maintenance.

Regardless, my patch set changes the availability and semantics of the 
device-mapper udev properties, and thus we should bump the version, no?

Thanks,
Martin


  reply	other threads:[~2024-03-04 16:46 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-01 22:40 [RFC PATCH 0/7] device mapper udev rules rework Martin Wilck
2024-03-01 22:40 ` [RFC PATCH 1/7] 13-dm-disk.rules: import ID_FS_TYPE Martin Wilck
2024-03-04 10:37   ` Peter Rajnoha
2024-03-04 15:17     ` Martin Wilck
2024-03-04 15:44       ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 2/7] 10-dm.rules: don't deactivate devices for DISK_RO=1 Martin Wilck
2024-03-04 10:48   ` Peter Rajnoha
2024-03-04 11:19     ` Peter Rajnoha
2024-03-04 11:27       ` Peter Rajnoha
2024-03-04 15:21         ` Martin Wilck
2024-03-04 16:09     ` Martin Wilck
2024-03-05  8:09       ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 3/7] 10-dm-rules: don't restore DM_UDEV_DISABLE_OTHER_RULES_FLAG from db Martin Wilck
2024-03-04 10:49   ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 4/7] 11-dm-lvm.rules: " Martin Wilck
2024-03-04 10:51   ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 5/7] dm udev rules: don't export and save DM_SUSPENDED Martin Wilck
2024-03-04 11:00   ` Peter Rajnoha
2024-03-04 16:21     ` Martin Wilck
2024-03-05  8:19       ` Peter Rajnoha
2024-03-05  8:47         ` Martin Wilck
2024-03-05  9:10           ` Peter Rajnoha
2024-03-05  9:28             ` Martin Wilck
2024-03-01 22:40 ` [RFC PATCH 6/7] dm udev rules: don't export and save DM_NOSCAN Martin Wilck
2024-03-04 11:03   ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 7/7] 10-dm.rules: bump DM_UDEV_RULES_VSN to 3 Martin Wilck
2024-03-04 11:09   ` Peter Rajnoha
2024-03-04 16:46     ` Martin Wilck [this message]
2024-03-05  8:26       ` Peter Rajnoha
2024-03-05  9:04         ` Martin Wilck

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=1bfb001084b17ab60c57f4819711c7d91c461536.camel@suse.com \
    --to=mwilck@suse.com \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=hare@suse.de \
    --cc=linux-lvm@lists.linux.dev \
    --cc=prajnoha@redhat.com \
    --cc=teigland@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).