On Fri, 2018-09-14 at 13:41 +0200, Martin Wilck wrote:
>
> > The *second* commit introduces a new possible value for
> > DM_MULTIPATH_DEVICE_PATH - "2", meaning "this *might* be a multipath
> > device, but we're not sure yet." This *may* also be significant to
> > other rules, because there are several that use this check:
> >
> > ENV{DM_MULTIPATH_DEVICE_PATH}=="1"
>
> If you look at the multipath rules, you can see that the value "2" is
> never passed on to later rules. If the value "2" is seen by the rules,
> processing continues along the "maybe" path, and eventually reaches
> this code:
>
> LABEL="pretend_mpath"
> ENV{DM_MULTIPATH_DEVICE_PATH}="1"
> ENV{SYSTEMD_READY}="0"
> GOTO="end_mpath"
That's what I thought, but it's not really 100% clear and I wasn't at
all sure whether there was something else I was missing which could
lead to the 2 value 'escaping'.
> That could be better documented by comments, I suppose.
That'd be nice, yes. =) Thanks.
> In short, code that tests for ENV{DM_MULTIPATH_DEVICE_PATH}=="1" to
> skip actions is fine. Code that checks for empty
> ENV{DM_MULTIPATH_DEVICE_PATH} should be fixed.
>
> Regards,
> Martin
>
> PS: This touches a very general topic about udev: to which extent are
> udev variables "global" in the sense that other, independent rules are
> allowed to inspect (and maybe even change) them? I don't think there
> are any clear conventions about this. Very few variables are obviously
> intended to be global, like "SYSTEMD_READY", but others are rather
> confined to the code that creates them, and maybe dedicated consumers.
> IOW, there is no "API" or standard describing how rule sets from
> different packages maintained by different people should interact.
I don't know. I think I noticed some rules files using a convention of
prefixing 'private' variables with _.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
