On Mon, 2022-06-27 at 13:34 +0200, Zbigniew Jędrzejewski-Szmek wrote: > > I'm not "blaming" the tools, I completely understand that they were > written a long time ago. But in fact the issue is fairly generic: any > software which interacts with devices that udev also touches MUST > wait > for udev to be done with the device. It's not just the MAC address > policy, but also other rules that users may configure locally, sysctl > configuration, etc. Without synchronization, one runs into races and > errors from the tools when they try to configure things in parallel. Yes, any software is well advised to wait for udev. But if it were not for MACAddressPolicy=, default Fedora would not ship much of relevant to make that necessary in practice. For example, NetworkManager's udev rules set some attributes. But those are mainly for NetworkManager itself (and NetworkManager knows to wait). If you have a tool that creates a software device, then there is no problem to not wait for those. Also, "other rules that the user confiugres locally", are entirely user's choice. Of course, the tools that this user runs, need to interoperate with the user's environment. > > > > IMHO The more compelling reason is compliance with MAC address > > filtering > > applied to VMs. > > FWIW, conditionalizing the policy on ConditionVirtualization=!vm > would > be trivial to add… Maybe having ConditionKernelCommandLine= could allow convenient customization for users and could be set by CoreOS (or suggested/documented). Thomas _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
