nic enumeration
in [Kernel]
|
Prev: Fix uninitialized variable warning in do_one_initcall
Next: net/ipv4/ip_output.c: Removal of unused variable in ip_fragment()
From: Loke, Chetan on 9 Jul 2010 14:30 > -----Original Message----- > From: Steve Fink [mailto:sphink(a)gmail.com] > Sent: July 09, 2010 1:11 PM > To: Loke, Chetan > Cc: Florian Weimer; linux-net(a)vger.kernel.org; Matt Domsch; Michael Di > Domenico; linux-kernel(a)vger.kernel.org; kay.sievers(a)vrfy.org > Subject: Re: nic enumeration > > On Fri, Jul 9, 2010 at 9:27 AM, Loke, Chetan <Chetan.Loke(a)netscout.com> > 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-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Loke, Chetan on 9 Jul 2010 15:10 > -----Original Message----- > From: Matt Domsch [mailto:Matt_Domsch(a)dell.com] > Sent: July 09, 2010 1:15 PM > To: Loke, Chetan > Cc: Florian Weimer; linux-net(a)vger.kernel.org; Michael Di Domenico; > linux-kernel(a)vger.kernel.org; kay.sievers(a)vrfy.org > Subject: Re: nic enumeration > > On Fri, Jul 09, 2010 at 12:27:53PM -0400, Loke, Chetan 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? > > Unlike disks which have /dev/disk/by-{id,path,uuid}/* symlinks back to > /dev/sd*, which udev manages, network devices have no such on-disk > representation for udev to manage. My proposal to create such on-disk > mappings was shot down, as was my suggestion to create (multiple) > network device symlinks/references/aliases inside the kernel. > Ok, I'm reading your link below/libnetdevname and original patch too. I'm willing to bend over to get something done. It's so much better than getting repeatedly tortured by customers. > FWIW, I have a talk at LinuxCon Boston coming up on this, and have a > proposal in for Linux Plumbers Conference as well. > > Thanks, > Matt > Regards Chetan Loke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Steve Fink on 9 Jul 2010 17:30 On Fri, Jul 9, 2010 at 11:23 AM, Loke, Chetan <Chetan.Loke(a)netscout.com> wrote: >> -----Original Message----- >> From: Steve Fink [mailto:sphink(a)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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Loke, Chetan on 12 Jul 2010 13:00 > -----Original Message----- > From: Steve Fink [mailto:sphink(a)gmail.com] > Sent: July 09, 2010 5:27 PM > To: Loke, Chetan > Cc: Florian Weimer; linux-net(a)vger.kernel.org; Matt Domsch; Michael Di > Domenico; linux-kernel(a)vger.kernel.org; kay.sievers(a)vrfy.org > Subject: Re: nic enumeration > > > Your problem is different from the one that began this thread. Can you > describe your situation more fully? > Sorry guys, I thought I mentioned my requirement. And I apologize for pulling in my discussion in this thread. Requirement: I've a box with 'M' NICs. During install time, all the h/w config is static, customers will configure the box. They would say use 'ethX' for task-foo and 'ethY' for task-bar. All this while our-apps where happy because we would never modify the h/w config(single NIC vendor). So the configuration was pretty static. However, we now let customers add/replace NICs from different vendors(so different drivers will get loaded).The older 'ethX' might now map to a newly-inserted-NICs-mac. So I would now like an 'ethX' agnostic way of addressing the NICs and BTW we can't reboot the box[look below why]. Possible solution: S1)I thought symlink[or a reference etc] would solve this problem. S2)I have another idea in mind(using mac-ids,enhance dev_ioctl[introduce SIOCGHWADDR_TO_IFNAMEINDEXMAP] and traverse for_each_netdev::for_each_dev_addrs) but I will wait for everyone's suggestions because there might be an easy way. Why can't I reboot? Imagine the above configuration within a VM. Some customers have as many as 75+ VMs deployed and we cannot afford to reboot the VMs after adding a new (virtual)vNIC. The newly added vNIC is seen by the guest as if it were a hot-insertion. > 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.) Why a bridge? Just to get around naming issues? Regards Chetan Loke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Steve Fink on 12 Jul 2010 14:30
>> 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.) > > Why a bridge? Just to get around naming issues? Yes. I wasn't claiming it was a *good* way to fix it. Just wondering if it would work. I have no idea whether it makes sense or not, not really knowing much about this stuff myself. I tried it on my workstation. It's a good way to kick yourself off the network. But it does work in the simplest possible case, if you fix up routing afterwards. I don't know whether bridges can be usefully used by VMs. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |