[systemd-devel] networkd-218 seems to ignore .link files

[Tom Gundersen]

On Tue, May 19, 2015 at 6:57 PM, Jan Engelhardt <jengelh at inai.de> wrote:
>
> On Tuesday 2015-05-19 18:38, Tom Gundersen wrote:
>>>> > # networkctl status --no-pager eth0
>>>> > ??????● 3: eth0
>>>> >    Link File: n/a
>>>> > Network File: n/a
>>>> >         Type: ether
>>>> >        State: off (unmanaged)
>>>> >         Path: pci-0000:01:00.0
>>>> >       Driver: r8169 [...]
>>>> > # cat /etc/systemd/network/01-mgmt.link
>>>> > [Match]
>>>> > Path=pci-0000:01:00.0
>>>> > Type=ether
>>>>
>>>> Type must be the same as what is returned in DEVTYPE=, which I guess
>>>> is unset for this device. So drop this and it should work.
>>>>
>>>> I see where the confusion stems from though, as we try to be helpful
>>>> and use a heuristic to print a Type in networkctl even when the kernel
>>>> does not expose a type. [...]
>>>
>>> What precisely is the heuristic?[...]
>>
>>There are two 'types', the ARP hardware identifier (link type as
>>exposed over rtnl) and the DEVTYPE (as exposed by libudev). The
>>matching logic only uses DEVTYPE.
>
> Unlike hwdevtype, arphrd is at least set _all the time_.

True, but not always to something useful (which is why we special case
ARPHRD_ETHER and DEVTYPE==wlan|wwan).

>>The output of networkctl (and the udev naming to a more limited degree) uses
>>the ARP hardware identifier and then falls back to DEVTYPE in the case of
>>ethernet devices to distinguish wlan and wwan interfaces from other kinds of
>>ethernet interfaces.
>>
>>In an ideal world, we would only use DEVTYPE and the kernel would
>>assign this reasonably to all devices. In the meantime we could do
>>some combination of DEVTYPE and ARPHRD, but the danger here is that we
>>will lock ourselves into some heuristic and make it impossible to
>>improve the kernel DEVTYPE's in the future as it would change the
>>behavior of current setups, which is why I have preferred to not
>>support any matching when DEVTYPE is not set. I'm very open to change
>>this if anyone has a convincing scheme in mind though.
>
> So, perhaps just making networkd support both DevType={match on DEVTYPE string}
> and LinkType={ether,loopback,other ARPHRD_* constants} be the interim solution
> for that.

I'd rather we just decide on some scheme once and for all. Interim
solutions have a way of becoming permanent...

-t