On Wed, Oct 28, 2009 at 09:23:57AM +0100, Kay Sievers wrote: > 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. > > 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. While we could do this without any kernel changes at all, it does still leave unresolved the concern of the in-kernel users of netdevice-by-name - everything that uses dev_get_by_name(), and any userspace tool that doesn't get converted to use the netdevice-by-path concept. Which brings us back to still looking for options. Multiple names for the same device gives us a way out. Users of the ethX naming convention continue unchanged, and live with the nondeterminism; Users of other naming conventions can get names that work for them, with needed determinism. Netdev team - are you in agreement that having multiple names to address the same netdevice is a worthwhile thing to add, to allow a variety of naming schemes to exist simultaneously? If not, this whole discussion will be moot, and my basic problem, that the ethX naming convention is nondeterministic, but we need determinism, remains unresolved. Assuming we agree it's worthwhile, I'm open to ideas for ways to solve it. We've proposed char devices for udev to manage, and fixing up userspace programs, but that doesn't solve in-kernel users by name. Dann proposed another method (above) which Kay isn't fond of, and which has the same drawback. I need another option then. Thanks, Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- 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
