Networkd vs interface renaming#11881
Conversation
poettering
left a comment
poettering
left a comment
There was a problem hiding this comment.
I wonder if it wouldn't be better to keep the property name entirely generic. There might be other subsystems that implement the "move" action, and trigger it from "add" by renaming the device (or otherwise doing something to it). And I think it would make sense to allow the property to be used for those things too.
hence maybe rename ID_NET_RENAMING_TO to ID_RENAMING= and make it a boolean? (i mean, we don't need the actual iface name we are renaming to as a prop, do we? a boolean would suffix too, no?)
|
I think this is quite an important fix btw, not just for networkd, but any consumer. I figure the NM folks should take notice of this too, and ignore ifaces that have the prop set. @lkundrak ping |
poettering
added
the
reviewed/needs-rework 🔨
yuwata
force-pushed
the
networkd-vs-interface-renaming
branch
from
38ee9fa to
8e26dec
Compare
|
@poettering Updated. The above two tiny comments are addressed in the updated version. But the name |
yuwata
removed
the
reviewed/needs-rework 🔨
Actually renaming itself may not limited to network interfaces, but currently
If boolean is enough, meybe we should use a tag? |
Well, but other components might do it too, for example from some program they ship that is run from "add". And I think it would make a ton of sense, to allow them to follow the same semantics them, and use the same property for this. I mean, I figure in PID 1 and such we should also check this new prop, and probably for all devices, so that devices don't show up under their old temporary name at all when they are renamed anyway. And for that having a generic name would be great since PID 1 of course synthesizes .device units for all kinds of device types, not just net ifs |
tags come at a price. the more oyu have the "fuller" the per-udev-msg bloom filter becomes, and that destroys the filtering caps. Hence, people shouldn't use tags unless they actively want to use it for matching devices. i.e. if somebody asks the question "please tell me all devices that are currently being renamed", then a tag would be right, but if nobody asks questions like that it should be a regular prop. (and yes, i don't think anyone would ask that question, wouldn#t you agree?) |
yuwata
added
the
reviewed/needs-rework 🔨
|
Thank you for the explanation. I will update this tomorrow or later. |
And drop the property on the corresponding 'move' uevent.
yuwata
force-pushed
the
networkd-vs-interface-renaming
branch
from
8e26dec to
c30eeee
Compare
Before the renaming, wrong .network file may be assigned to the link. So, let's always drop link configuration.
It will be used in the later commit.
yuwata
force-pushed
the
networkd-vs-interface-renaming
branch
from
c30eeee to
8413057
Compare
|
@poettering Updated.
|
yuwata
removed
the
reviewed/needs-rework 🔨
systemd-networkd itself does not start dhcp client, but the code may be used in other projects. So, check that the interface is under renaming or not.
yuwata
force-pushed
the
networkd-vs-interface-renaming
branch
from
8413057 to
2304168
Compare
2 participants
Previously,
networkddoes not synthesize 'move' uevent, and if an interface is passed through uevent or netlink and with valid udev database, the interface is assumed to be initialized.But, if the interface renaming is requested, it induces move uevent. So, some racy situations between
networkdandudevmay exist.This adds
ID_NET_RENAMING_TOproperty to udev database when an interface renaming is requested, and the property will be dropped when the correspondingmoveuevent is processed. And this makesnetworkdcheck whether the property exists or not before configuring interfaces.I am not sure, but this may fix #7293.