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