network-generator: split out udev pieces from systemd-network-generator

[dustymabe]

Component

systemd-network-generator

Is your feature request related to a problem? Please describe

The udev pieces of systemd-network-generator are useful even if you aren't using systemd-networkd on your system (i.e. using NetworkManager, or other). It's mostly harmless to have systemd-network-generator to generate networking configuration if the sytsemd-networkd isn't enabled, but it is misleading:

• the user might not understand that the .network files aren't used for anything
• any failures may lead the user chasing an error that is only cosmetic
  • See systemd-network-generator support for ip=NIC:dhcp,dhcp6 #27944 for a real world example of a cosmetic failure here.

This is a continuation of the discussion in #21766 (comment)

Describe the solution you'd like

Break out the udev pieces into a new service that can operate independently of systemd-networkd.

Describe alternatives you've considered

Leaving it like it is today. Sure failures are cosmetic, but ultimately the design would be better if these two things that are responsible for different pieces were independent.

The systemd version you checked that didn't have the feature you are asking for

No response

[dustymabe]

can someone please add the network label to this? Sorry I missed the Component when I first opened the issue.

[keszybz]

We could do the split only at installation level: e.g. make systemd-network-generator a multi-call binary, and only write out the link files from systemd-link-generator. If we do this, I think this would be most reasonable way.

There is a non-negligible cost to splitting things into tiny bits. Mostly when all the bits are used together: things are a bit slower, there's bigger chances of missing some integration, etc. If the are some warning emitted during parsing, both generators would emit them. OTOH, the additional cost of writing a few network files if they are not used is negligible.

So I would lean towards just fixing any bugs which cause warnings to be emitted. We want and need to fix those, and then the motivation for this RFE is mostly removed.

[poettering]

humpf. should we really bother with this? if people don't want networkd, great, but then they should carry the burden for that, and reimplement network management as they see fit themselves.

(Also, I mean, in general in 2023, does anyone still really want to use NM? isn't this over now in the cloud?)

[keszybz]

I'm pretty sure we should. NM is alive and well, and there are also other approaches that people use.