On Tue, Oct 27, 2009 at 21:55, Matt Domsch <Matt_Domsch@xxxxxxxx> wrote: > On Thu, Oct 22, 2009 at 12:36:20AM -0600, dann frazier wrote: >> Here's a proof of concept to further the discussion.. >> >> The default filename uses the format: >> /dev/netdev/by-ifindex/$ifindex >> >> This provides the infrastructure to permit udev rules to create aliases for >> network devices using symlinks, for example: >> >> /dev/netdev/by-name/eth0 -> ../by-ifindex/1 >> /dev/netdev/by-biosname/LOM0 -> ../by-ifindex/3 >> >> A library (such as the proposed libnetdevname) could use this information >> to provide an alias->realname mapping for network utilities. > > yes, this could work, as IFINDEX is already exported in the uevents, > and that's the primary value udev needs to set up the mapping. > > While I like the little ifindex2name script you've got, I think udev > could simply call if_indextoname() to get this, and not call an > external program? I suppose it could be a really really simple > external program too. What's the point of all this? Why would udev ever need to find the name of a device by the ifindex? The device name is the primary value for the kernel events udev acts on. > I'd be fine with this approach. It has the advantages of not > requiring a kernel change at all, and not creating a whole character > device which would be useless. And it doesn't preclude someone in the > future from creating a char device for network devices should they so > choose. > > Kay, what say you as udev owner? That all sounds very much like something which will hit us back some day. I'm not sure, if udev should publish such dead text files in /dev, it does not seem to fit the usual APIs/assumptions where /sys and /dev match, and libudev provides access to both. It all sounds more like a database for a possible netdevname library, which does not need to be public in /dev, right? Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
