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
| ||
|
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
Powered by blists - more mailing lists