Re: renaming kernel devices [was: VIA EPIA EK: strange eth dev numbering]

From: Michael Tokarev
Date: Thu Aug 02 2007 - 09:36:59 EST


Jan Engelhardt wrote:
> On Aug 2 2007 16:56, Michael Tokarev wrote:
>>>> I already can see comments from udev/sysfs maintainers here: "naming
>>>> is a policy which does not belong to kernel". It's a bullshit, because
>>>> kernel too has to use SOME way to name things,
>>> (1) The kernel starts with ethX
>>> (2) udev renames it to something else
>>> (3) kernel uses new name too ("ni0: link down")
>> And now tell me please how can I connect two messages from dmesg:
>>
>> eth0: Tigon3 [partno(BCM95721) rev 4201 PHY(5750)] (PCI Express) 10/100/1000Base-T Ethernet 00:14:5e:5d:18:26
>> nic10: Link is up at 100 Mbps, full duplex.
>
> Generally, the "link is xyz" message comes directly after loading the module,
> so it should be eth0 before udev gets a chance to rename it. Or maybe not -
> in which case, well, you're literally fubared, and your distro should put a
> "renamed A to B" into syslog.

Yes, first message is generated before udev has a chance to act.
And no, I just don't use udev, and I hope very much that it will
not become required (it is slowly becoming - for example, some
packages on Debian (like xen for example) now explicitly depends
on udev - but so far I managed to satisfy this dependency by
other means).

>> What I wanted to say (here with network devices, and with disk names
>> and everything else) is -- as long as the device is here (plugged in
>> but not yet unplugged), I want it to have the same "primary" name in
>> kernel and in userspace, so that everything
>
> Oh I think it already has a "primary name" today --
>
> $ readlink /sys/class/net/eth0/device
> ../../../../../devices/pci0000:00/0000:00:04.0
>
> there is your primary name, and your secondary name is ethZ. :)

This primary name isn't at all useful - I can't ifconfig or fdisk it,
and it's not shown in log/dmesg either.

/mjt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/