> -----Original Message----- > From: Steve Fink [mailto:sphink@xxxxxxxxx] > Sent: July 09, 2010 1:11 PM > To: Loke, Chetan > Cc: Florian Weimer; linux-net@xxxxxxxxxxxxxxx; Matt Domsch; Michael Di > Domenico; linux-kernel@xxxxxxxxxxxxxxx; kay.sievers@xxxxxxxx > Subject: Re: nic enumeration > > On Fri, Jul 9, 2010 at 9:27 AM, Loke, Chetan <Chetan.Loke@xxxxxxxxxxxx> > wrote: > > Ok, no renaming, I would like a reference. And symlink just doesn't > work > > w/ the udevadm trigger business. We've tried that already. > > > > What needs to be changed in udev etc to create a soft link? Any place > > where I should start digging and gotchas to lookout for? > > By "soft link", I assume you're talking figuratively? Yes, I was using it loosely. symlink == I would like 'udev' to do the linkage w/ the network-devices and create a reference to it. > Soft (symbolic) > links are a filesystem concept, implemented by filesystem-specific > logic that knows how to read a filename out of an inode and restart > lookup. In order for something similar to work for network devices, > somebody would have had to explicitly implement similar functionality. > (Symlinks are a big headache and source of security holes -- access > control, loops, pointing to nonexistent files, etc. -- so there's a > good reason to NOT have an equivalent for network devices.) > Huh? If the 'ethX' interface doesn't exist just don't create the 'link'. So are you saying there are no security issues with udev-symlinks for other subsystems? Why is renaming allowed on the network-interface then? Isn't that a problem? I don't see the driver re-registering their RX/TX queues with the new-if-name. May be I'm overlooking at something really obvious. But how are people managing [pv]drivers with multiple vNICs in their VMs if they need a consistent naming scheme? Regards Chetan Loke -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
