Hello Neil, On Wed, 2022-02-23 at 09:49 +1100, NeilBrown wrote: > > > > 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. > There's also some documentation in the form of comments in the device- mapper rules files themselves: https://github.com/lvmteam/lvm2/blob/8dccc2314e2482370bc6e5cf007eb210994abdef/udev/10-dm.rules.in#L137 In general, 10-dm.rules is one of the most extensively commented rule files. I've always found these comments quite helpful. > 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. I agree that the documentation could be improved. OTOH, the text in systemd.device(5) only explains how systemd itself interprets SYSTEMD_READY. It doesn't say a word about how other udev rules are supposed to deal with the device. IOW, SYSTEMD_READY is part of an API between udev rules and systemd, and not between different udev rule sets. In particular the "don't probe this iff SYSTEMD_READY==0" semantics that are frequently used in rules files can't be inferred from this documentation. It makes sense most of the time, but there are some cases where it doesn't. Here, we have a case where probing should be skipped, even though SYSTEMD_READY is not 0. Regards, Martin PS: The big issue remains that there is no "official" API in which udev rule sets can transport information between each other. I guess the original idea was that every rule set would be self-contained, which isn't the case any more. If anyone makes an effort redesign udev, they should consider creating such an API somehow. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
