Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753758Ab0GIV0e (ORCPT ); Fri, 9 Jul 2010 17:26:34 -0400 Received: from mail-vw0-f46.google.com ([209.85.212.46]:43061 "EHLO mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753311Ab0GIV0b (ORCPT ); Fri, 9 Jul 2010 17:26:31 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rX0NKQnx9jwCCcJIm07tYpUA3WQMT9Kw+PnoFVrEJZgYH/jSEK+SXai/LOoxz1U7Rx o4wxT+TLvSg3xssMRxLUiyovVln7aKNGn4HixjKQPWk3karqMA2PVtfFNG6LxmjV/dgv uzHY66bWeg3cdOoy4To4ahv2W9yKvP7/mLxpU= MIME-Version: 1.0 In-Reply-To: References: <20100708012120.GB11419@auslistsprd01.us.dell.com> <82tyo9i0n2.fsf@mid.bfk.de> Date: Fri, 9 Jul 2010 14:26:30 -0700 Message-ID: Subject: Re: nic enumeration From: Steve Fink To: "Loke, Chetan" Cc: Florian Weimer , linux-net@vger.kernel.org, Matt Domsch , Michael Di Domenico , linux-kernel@vger.kernel.org, kay.sievers@vrfy.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2120 Lines: 43 On Fri, Jul 9, 2010 at 11:23 AM, Loke, Chetan wrote: >> -----Original Message----- >> From: Steve Fink [mailto:sphink@gmail.com] >> >> 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/