On Mon, Aug 25, 2014 at 9:49 PM, Marcel Holtmann <mar...@holtmann.org> wrote: > Hi Tom, > >>>>>>>> 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. > > there has been a discussion on the wireless mailing list about exactly this > topic. Currently nl80211 only allows MAC address setup for P2P devices, but > the general agreement is that this should be extended to allow for any > interfaces. This is also useful for hardware that has not pre-configured MAC > address and where the address needs to be provided by userspace anyway. > > So this fix should be for the NL80211_CMD_NEW_INTERFACE to handle providing > the MAC address for all interface types.
Thanks Marcel, that's good to know! Cheers, Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
