netdev - Re: network interface *name* alias support?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 27 May 2008 14:03:52 -0500
From:	Matt Domsch <Matt_Domsch@...l.com>
To:	David Miller <davem@...emloft.net>
Cc:	kaber@...sh.net, jengelh@...ozas.de, dwmw2@...radead.org,
	jchapman@...alix.com, jonathan@...masters.org, tgraf@...g.ch,
	rick.jones2@...com, auke-jan.h.kok@...el.com,
	johnathan@...masters.org, netdev@...r.kernel.org
Subject: Re: network interface *name* alias support?

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html