Re: About DM_UDEV_DISABLE_OTHER_RULES_FLAG and DM_NOSCAN

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Martin






[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux