Steffen Dettmer a écrit : > > On Tue, Nov 19, 2013 at 11:24 PM, Pascal Hambourg > <pas...@plouf.fr.eu.org> wrote: > >> A "real" network interface has the (non-null) driver name in >> its parent device and thus matches the rule, whereas a "virtual" VLAN >> interface does not. > > Thank you for your explanation. I think I understood well, but > there seems to be a missing detail in my case: although for > almost any device this might be true, but as the "udevadm info" from > my original posting shows, there are drivers that do not do so. > (For such devices, the Debian udev scripts do not even generate > persistent net rules, because DRIVER must match non-empty in > the generator script). > > The driver used here is "ksz884x". > > If it is required that a driver for a physical network card sets > DRIVER and no other driver is allowed to do so (which IMHO would > be a precondition to safely bind udev rules on that), I think > this would indicate an issue with the driver "ksz884x". > > What do you think, is this right?
AFAICS the network interface device itself always has an empty DRIVER, however (at least one of) the *parent* devices should have a non-empty DRIVER, this is why the rules have DRIVERS and not just DRIVER. You did not show the parent devices for the eth interface. > (By the way, from a technical viewpoint I dislike the idea to > distinguish ethernet/parent/physical devices from virtual > devices like VLAN devices by determining the presence of a > DRIVER name. I tend to agree with you, this sounds a bit like a hack. > Also, different virtual devices, like VLAN and > [guessed] bridge interfaces would be indistinguishable. Indistinguishable from what ? >>> # Avoid renaming of VLAN interfaces: >>> SUBSYSTEM=="net", KERNEL=="eth*.*" ACTION=="add", NAME="$kernel" >>> >>> Of course this only works as long as following the naming >>> convention to call the VLAN interface "eth<X>.<V>" with <V> being >>> the number of the VLAN tag, for example "eth3.77". >> >> It does not matter : the other naming convention vlan<V> won't match the >> rule and thus won't be renamed, which is the desired behaviour IIUC. > > (assuming with "other naming convention" you mean the "standard > rules" as generated by Debian net rule generator:) No, I mean the other naming convention that can be used for VLAN interfaces. See man vconfig. You can select between ethX.V, ethX.VVVV, vlanV, vlanVVVV. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52952f09.2000...@plouf.fr.eu.org
