<div dir="ltr"><div>In regards to the OS and syntax, this is NixOS. NixOS uses its own expression language to configure the entire system, including the network stack. If a user wanted to configure their system's networking stack, they would modify the networking.* set of options in their /etc/nixos/configuration.nix. Currently this is done with a set of generated scripts run as systemd services with device based dependencies. Ideally this would be directly translated to networkd syntax.<br><br></div><div>For example, a user might have this snippet as part of their config for statically configuring one of their ethernet interfaces:<br><br></div><div>networking.interfaces."enp4s0" = {<br></div><div>  macAddress = "de:ad:be:eef:ca:fe";<br></div><div>  mtu = 9000;<br></div><div>  ip4 = [<br></div><div>    { address = "10.0.0.2"; prefixLength = 24; }<br></div><div>    { address = "10.0.0.3"; prefixLength = 24; }<br>  ];<br></div><div>};<br><br>For link configuration, we are currently generating a network-link-<ifname>.service which sets the mac address and mtu using iproute2:<br><a href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix#L691-L713">https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix#L691-L713</a><br><br></div><div>The networking options are all defined in:<br><a href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix">https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix</a><br></div><div><br></div><div>Our current translator to networkd is:<br><a href="https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces-systemd.nix">https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces-systemd.nix</a><br></div><div><div><br><br></div>Of course, the problem with just 
using kernel names is that our use case assumes that the interface was 
already renamed by udev. Therefore, our matching must be based on the 
post-udev name if it is to be backward compatible. Ultimately it might be best to continue using our set of scripts coupled with udev generated systemd device units, given our use cases.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 4, 2014 at 9:53 AM, Tom Gundersen <span dir="ltr"><<a href="mailto:teg@jklm.no" target="_blank">teg@jklm.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Dec 4, 2014 at 4:11 PM, Lennart Poettering<br>
<<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br>
> On Thu, 04.12.14 11:20, Tom Gundersen (<a href="mailto:teg@jklm.no">teg@jklm.no</a>) wrote:<br>
><br>
>> > I mean, most of the times .link files are<br>
>> > used to choose the name depending on other fields, but I think in all<br>
>> > cases where the name is chosen at creation time of an interface (like<br>
>> > for example for veth links), it should be Ok to match links based on<br>
>> > the name they already have?<br>
>><br>
>> So this we could do (i.e., allow name matches if and only if the name<br>
>> is set at creation time). Though, if the name is set at creation time,<br>
>> shouldn't also all the other properties have been?<br>
><br>
> In nspawn we create veth links, and I *really* *really* don't want to<br>
> add tons of options there to set the MTU or suchlike. Setting these<br>
> properties really should be done within networkd I think.<br>
><br>
> I think it would be really useful if we could match on the container's<br>
> veth links by name, so that a .link file for it could be equally<br>
> expressive as the .network file already is.<br>
><br>
>> Moreover, if we<br>
>> give people this feature I'm pretty sure we'll get lots of people<br>
>> expecting it to work also for any other sort of name and getting<br>
>> confused when it doesn't.<br>
><br>
> Well, this is something we can fix by documentation, no?<br>
><br>
> Or maybe name the match option differently, maybe OriginalName= or<br>
> KernelName= or so, and then only matching interfaces where you know<br>
> that the name was selected by userspace in the first place?<br>
<br>
</div></div>I like the idea of OriginalName, much less likely to get people<br>
confused. I now implemented that, with the restriction that we cannot<br>
match on renamed names. For now I left it open to match on ethX style<br>
names, as people in principle could do sensible things like<br>
"OriginalName=eth*" or even "OriginalName=eth0" when we know there is<br>
only one interface.<br>
<br>
One thing to consider would be to disallow renaming from a .link file<br>
where the OriginalName was used to match. That way we don't have the<br>
somewhat odd situation that a .link file can only be applied once (we<br>
do not remember the original name, so cannot match on that the second<br>
time around, as that would be a mess)...<br>
<br>
Testing and feedback welcome. Does this solve your problem William?<br>
<br>
Cheers,<br>
<br>
Tom<br>
</blockquote></div><br></div>