On 2/16/24 15:29, Martin Wilck wrote: > On Thu, 2024-02-15 at 17:45 -0500, Benjamin Marzinski wrote: >> On Mon, Feb 12, 2024 at 03:16:27PM +0100, Martin Wilck wrote: >>> On Mon, 2024-02-12 at 13:32 +0100, Peter Rajnoha wrote: >>> >>>> >>>> What do you think about keeping a single >>>> DM_UDEV_DISABLE_OTHER_RULES_FLAG for this, just having a >>>> different >>>> value, say "2" to denote the B case? Otherwise, we need 2 >>>> distinct >>>> variables (which is harder for others to accept I bet). >>> >>> Yes, that could work, if the save / restore is implemented cleanly. >> >> What if we never read DM_UDEV_DISABLE_OTHER_RULES_FLAG from the >> database. Instead how about, if DM_UDEV_DISABLE_OTHER_RULES_FLAG is >> set >> by "dmsetup udevflags", we save it as something like >> DM_IGNORE_DEVICE. >> Otherwise, if it's a spurious event, we read DM_IGNORE_DEVICE from >> the >> database. After "dm_flags_done", if DM_IGNORE_DEVICE is set, we set >> DM_UDEV_DISABLE_OTHER_RULES_FLAG. This leaves the other rules free to >> mess with DM_UDEV_DISABLE_OTHER_RULES_FLAG all they want. > > That sounds good and aligns with what I'd thought by myself. But we > should use a less suggestive name. DM_IGNORE_DEVICE would again make > users think that they should consume this variable, like DM_NOSCAN. > Yup, that looks reasonable and clean. Though, the DM_UDEV_DISABLE_OTHER_RULES_FLAG is only one flag from the whole set. To avoid handling only a single selected flag in a special way and to avoid issues raising from that, we might as well apply that logic to all the other flags decoded by `dmsetup udevflags`. -- Peter
