On Fri, Jul 9, 2010 at 11:23 AM, Loke, Chetan <Chetan.Loke@xxxxxxxxxxxx> wrote: >> -----Original Message----- >> From: Steve Fink [mailto:sphink@xxxxxxxxx] >> >> 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. The issues are different between network device and filesystem names, yes. I was just saying that symbolic linking / aliasing are tricky. udev symlinks introduce no *new* security issues because they're filesystem links. Renaming the network interface certainly does cause problems. And I don't know how the queues are connected to the devices internally, but I doubt it's by 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? Your problem is different from the one that began this thread. Can you describe your situation more fully? I only partially understand your problem, but I am still wondering if my bridge idea would work for you. (Preferably combined with udev rules or whatever so the bridges are unnecessary after the next reboot.) -- 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