Hannes Reinecke wrote:

And to throw in some bit of useless information;

Stirring the pot a bit myself with this message...

The one reason I didn't to this was that a network interface is _not_
a file, but rather an abstract type which is known only internally in
the kernel (ie the one exemption from the 'everything is a file' UNIX
rule).

Why?  Why not make it a file?  I've heard rumors of other Unix-like
systems that do exactly that, FWIW.

(Yes, I'm joking.  Well, maybe half-joking...  It'd be nice, but I don't
expect it to happen.)

When I were to design this, I would be implementing network interface
_aliases_, so that a network interface could be accessed either by 
name or by alias. This mechanism can then be managed by udev, much 
like we (ie SUSE) is using it nowadays to assign the network
interface numbers.

The problem with that, if I understand what you're suggesting, is the
value of IFNAMSIZ, and the fact that it can't be made any bigger.  All
your aliases have to be IFNAMSIZ characters or less.  And that's too
short to be able to embed the same level of information as we get for
e.g. disks.  It's *barely* long enough to fit "mac-" plus 12 hex digits
(for the MAC address), but is completely incapable of holding a USB bus
path, for instance.

(Not that you'd want to use path persistence for USB devices.  But it is
possible that you'd want it for some other setup, at which point it
becomes impossible to use the same rules for USB.)