Mathieu Othacehe <othac...@gnu.org> skribis: >> Can we instead use <network-link> for these purposes? It is already >> there, just unused.
BTW, for the purposes of fixing the bug you initially reported, I suggest simply adding #:multicast-on #t as you initially proposed. We discuss the proper API separately. > Mmh, indeed. Well it is already used to create vlan and veth > interfaces. What we could do then, is expose the <network-link> record > as a direct equivalent of the Guile-Netlink <link> record. > > The links list of the <static-networking> record would contain all the > links that are managed by Guix. We would require all "device" fields > that appear in the <network-address> records to have their matching link > declared. If the link doesn't already exists (vlan, veth type) then > link-add is called, otherwise nothing happens. The link existence can be > tested using link-name->index. link-set would always be called > afterwards to setup link properties. > > static-networking-shepherd-service would then create on service per link > present in the <static-networking> links list. The provisioned name > would be (concat 'networking- (network-link-name link)). > > On tear down, which is equivalent to "herd stop networking-<link>", we > would call link-del if the link was created by Guix with link-add, or > (link-set ... #:down #t) if the link was already present. I'm not sure > how to distinguish between those two cases at this step. > > This sounds like a complex plan, that will moreover require and > adaptation of existing static-networking configurations, but I cannot > think of anything easier to fix this issue and the other one I reported. Hmm yeah. I think it’s good to have defaults right, so #:up and #:multicast-on set. We could set those when a device lacks a corresponding link. Food for thought… Ludo’.