[systemd-devel] Match section of .link file not working

Tom Gundersen teg at jklm.no
Mon Aug 25 12:44:13 PDT 2014


On Mon, Aug 25, 2014 at 9:27 PM, Simon Peeters <peeters.simon at gmail.com> wrote:
> 2014-08-25 19:46 GMT+02:00 Kay Sievers <kay at vrfy.org>:
>> On Mon, Aug 25, 2014 at 7:25 PM, Lennart Poettering
>> <lennart at poettering.net> wrote:
>>> On Sun, 24.08.14 06:49, Simon Peeters (peeters.simon at gmail.com) wrote:
>>>
>>>> >> This should be the value of ID_PATH property, not sysfs path. Check with
>>>> >>
>>>> >> udevadm info --query
>>>> >> property /sys/devices/ocp.3/47400000.usb/musb-hdrc.1.auto/usb1/1-1/1-1:1.0/net/wlv3
>>>> >
>>>> > oops, I confused ID_PATH with DEVPATH, now i feel like an idiot.
>>>
>>> ID_PATH is basically the "reduced + stable" part of the full sysfs path.
>>>
>>>> Ok, so there is only one problem now:
>>>> ID_PATH is the same for all my vif interfaces, and i need to select
>>>> only one of them.
>>
>> ID_PATH usually describes the "parent hardware", and the same hardware
>> can have multiple independent devices. Unique names for several
>> devices need to be composed by appending something to the "parent
>> hardware".
>>
>> I don't have a good idea what a working model for your case would be,
>> where multiple devices share the same parent. This is not a common
>> model.
>>
>>> This is some embedded device with your hw connected to some platform
>>> bus?
>>>
>>> Currently the ID_PATH logic doesn't understand platform busses (since it
>>> is not clear how "stable" they are). This has come up before, and could
>>> probably be fixed. Maybe we should assume that platform busses are
>>> always enuemrated in a stable way, dunno.
>>>
>>> Kay probably has something useful to say here. Kay?
>>
>> Special buses need explicit support in the code if ID_PATH is not
>> generated, but that does not look like the problem here.
>>
>> Seems the USB interface exports 3 different network devices. Do they
>> have any unique property? Like dev_id, dev_port in /sys? Or are the
>> types of the netifs unique?
>
> Well, as posted earlier , these are virtual interfaces, kind of the
> vlans for wifi (allows to connect ot multiple networks on a same phy).
> (sory for not precise enough in the original post)
> So they do not realy have something unique and stable appart from the name.
>
> I think there are 3 posible ways to go forward:
>  - fix iw (and maybe the kernel to) to support a mac address parameter
> at interface creation time (so the mac is set even before udev sees
> it)

I really think this is the correct way to go. If something is being
created from userspace, it should just be created correctly in the
first place.

Cheers,

Tom

>  - Add vif netdev support to networkd similar to how vlans are
> handled, also alowing to set the mac address.
>  - Support [Match] Name= in .link files, even if it is with a large
> warning, or even as an unsupported "ymmv" option (because names are
> normaly not stable)
>
> 1. could be hard if the kernel does not support this, which i havn't
> checked yet.
> 2. would be ideal and could also work in most cases if the kernel does
> not support this in an atomic operation (since networkd can not race
> with itself)
> 3. this would be the easy, almost lazy, way, but would also work with
> wathever wierd exotic virtual device the kernel developrs come up
> with.
>
> I noted this boils down to almost the same discution there was a while
> ago under the title: "[systemd-devel] systemd-networkd: setting the
> MAC address for a .netdev unit?"[0] with the only difference that
> .netdev support for vif's not yet exists. (so I do this in a separate
> unit)
>
>> If anything like that is available, that could be appended to the
>> parent ID_PATH string and identify the device uniquely, if you get
>> what I mean.
>
> nah, I don't think so, I can check but the only thing i can imagine is
> the name passed during creation, or maybe some sequence id, but I am
> not sure wether that would be usable.
>
>> Kay
>
> [0] http://lists.freedesktop.org/archives/systemd-devel/2014-April/018712.html
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel


More information about the systemd-devel mailing list