Re: network interface *name* alias support?

[Matt Domsch <Matt_Domsch@dell.com>]

On Sun, May 25, 2008 at 05:17:13AM -0700, David Miller wrote:
> Physical geography information for a device is available
> to userspace already.  If tools want to present that to
> the user in a suitable interface, fine.  But what is
> being proposed here is not necessary to implement that.

OK, I'm just trying to understand how you would see this "feature"
being implemented in userspace.  Advice welcome.

I keep looking at my analogue: disk devices.

Disks have a hard-coded association: Some device node with number
(8,0) means "the first SCSI disk device" to the kernel.  Regardless of
what the name of the file that implements the device node is (probably
/dev/sda, but not necessarily), or if there are symlinks pointing at
that file.  The kernel only cares about the linkage between the device
node and the driver that accepts read/write/ioctl/etc. to it.

Network devices have no such thing that I can tell.  I get at the
device names (as presently assigned) by reading /proc/net/dev (I'd be
happy to be told of a more correct way - this is what net-tools uses.)
The moment I've finished reading this though, another process can come
along and change these devices names.  Now every ioctl() my code makes
could fail because the name (in struct ifreq) is the handle used for
such calls.  One could argue it's a rare thing to change device
names...

This still leaves us the problem of wanting perhaps several naming
policies: by logical use, by physical geography, by kernel enumeration
name, etc.  Every tool that interacts with device names would need to
be modified to get at these "new names" to make use of them,
which are then translated (in userspace) to the current matching
kernel name, which is then used to make the ioctl() calls.  And we'll
have to persist these "new names" (assuming they aren't always
computable - e.g. the udev persistent net names rules today -
certainly we'd have to do that for any logical use naming policy; 
agreed the persistance mapping would have to exist in userspace).

Something like that?

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux