Re: About DM_UDEV_DISABLE_OTHER_RULES_FLAG and DM_NOSCAN

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

 



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





[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux