From: Ben Hutchings <bhutchings@solarflare.com>
To: Jordan_Hargrave@Dell.com
Cc: netdev@vger.kernel.org, linux-hotplug@vger.kernel.org
Subject: Re: PATCH: Network Device Naming mechanism and policy
Date: Wed, 19 Aug 2009 20:26:25 +0100 [thread overview]
Message-ID: <1250709985.2874.41.camel@achroite> (raw)
In-Reply-To: <5DDAB7BA7BDB58439DD0EED0B8E9A3AE011CD964@ausx3mpc102.aus.amer.dell.com>
On Wed, 2009-08-19 at 13:56 -0500, Jordan_Hargrave@Dell.com wrote:
> This is from an old discussion several months ago:
> http://lkml.org/lkml/2009/3/24/357
> http://lkml.org/lkml/2009/3/24/380
>
> Basically the issue is that between a race in udev and PCI scan order the ethX IDs may not
> be consistent between reboots. The idea is to use a mechanism similar to how disks now can
> be accessed by their LABEL/PATH/UUID instead of raw /dev/sdX ids.
>
> example udev config:
> SUBSYSTEM=="net", SYMLINK+="net/by-mac/$sysfs{ifindex}.$sysfs{address}"
> SUBSYSTEM=="net", PROGRAM="/sbin/biosdevname -i %k --policy=all_names", SYMLINK+="net/by-chassis-id/%c"
>
> The following patch will create a device node for network devices based off their ifindex;
> udev can then use this device node for creating symlinks in /dev/net/xxxx similar to the
> way that disks now use by-label and by-path symlinks.
>
> Combining this with the biosdevname utility and patches to common network utilities,
> it could be possible to access ethernet devices by their PCI path or BIOS Label.
>
> eg. ifconfig Embedded_NIC_1
Nice idea, but wouldn't it be "ifconfig LABEL=Embedded_NIC_1"?
> --- include/linux/major.h~ 2009-07-30 18:34:47.000000000 -0400
> +++ include/linux/major.h 2009-08-05 14:52:10.000000000 -0400
> @@ -169,6 +169,7 @@
> #define IBM_FS3270_MAJOR 228
>
> #define VIOTAPE_MAJOR 230
> +#define NETDEV_MAJOR 234
>
> #define BLOCK_EXT_MAJOR 259
> #define SCSI_OSD_MAJOR 260 /* open-osd's OSD scsi device */
> --- net/core/net-sysfs.cx 2009-08-05 15:00:13.000000000 -0400
> +++ net/core/net-sysfs.c 2009-08-05 15:01:20.000000000 -0400
> @@ -11,6 +11,7 @@
>
> #include <linux/capability.h>
> #include <linux/kernel.h>
> +#include <linux/major.h>
> #include <linux/netdevice.h>
> #include <linux/if_arp.h>
> #include <net/sock.h>
> @@ -496,6 +497,7 @@ int netdev_register_kobject(struct net_d
> dev->class = &net_class;
> dev->platform_data = net;
> dev->groups = groups;
> + dev->devt = MKDEV(NETDEV_MAJOR, net->ifindex);
[...]
Since this major number is unregistered, the device inode can only be
stat'd and not open'd, which seems like a bit of a hack. Is there
anything that would stop register_chrdev(0, ...) from allocating this
major number, causing network devices to be confused with some other
device type?
Maybe there *should* be character devices for network device
manipulation. It seems like that would avoid the race conditions that
device renaming and removal causes for name-based socket ioctls. But
maybe everyone should be using netlink for that instead.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2009-08-19 19:26 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5DDAB7BA7BDB58439DD0EED0B8E9A3AE011CD92D@ausx3mpc102.aus.amer.dell.com>
2009-08-19 18:56 ` PATCH: Network Device Naming mechanism and policy Jordan_Hargrave
2009-08-19 19:26 ` Ben Hutchings [this message]
2009-08-19 19:40 ` Jordan_Hargrave
2009-08-20 4:41 ` Bryan Kadzban
[not found] <EDA0A4495861324DA2618B4C45DCB3EE5894ED@blrx3m08.blr.amer.dell.com>
2009-10-09 14:00 ` Narendra K
2009-10-09 14:51 ` Matt Domsch
2009-10-09 16:23 ` Bryan Kadzban
2009-10-09 16:56 ` Marco d'Itri
2009-10-12 10:41 ` Scott James Remnant
2009-10-12 11:31 ` Ben Hutchings
2009-10-12 17:37 ` Bill Nottingham
2009-10-13 18:06 ` Dan Williams
2009-10-13 18:53 ` Ben Hutchings
2009-10-13 19:53 ` John W. Linville
2009-10-09 16:36 ` Greg KH
2009-10-09 17:17 ` Matt Domsch
2009-10-09 17:22 ` Greg KH
2009-10-09 21:09 ` Matt Domsch
2009-10-10 2:44 ` Stephen Hemminger
2009-10-10 4:40 ` Matt Domsch
2009-10-10 5:23 ` Greg KH
2009-10-10 8:17 ` Sujit K M
2009-10-10 16:27 ` Greg KH
2009-10-10 19:00 ` Ben Hutchings
2009-10-10 21:10 ` Greg KH
2009-10-10 12:47 ` Matt Domsch
2009-10-10 16:25 ` Greg KH
2009-10-10 17:34 ` Bryan Kadzban
2009-10-10 21:13 ` Greg KH
2009-10-12 6:21 ` Bryan Kadzban
2009-10-12 16:19 ` Bryan Kadzban
2009-10-11 16:40 ` David Zeuthen
2009-10-11 18:47 ` Greg KH
2009-10-10 18:11 ` Bill Fink
2009-10-10 18:35 ` Kay Sievers
2009-10-11 21:10 ` Rob Townley
2009-10-11 23:04 ` Matt Domsch
2009-10-12 3:00 ` Greg KH
2009-10-12 18:35 ` Rob Townley
2009-10-12 18:44 ` Matt Domsch
2009-10-12 17:45 ` Bill Nottingham
2009-10-12 17:55 ` Greg KH
2009-10-12 18:07 ` Bill Nottingham
2009-10-12 18:15 ` Greg KH
2009-10-10 18:32 ` Stephen Hemminger
2009-10-10 21:06 ` Greg KH
2009-10-13 18:02 ` Dan Williams
2009-10-13 18:53 ` Narendra_K
2009-10-12 7:30 ` Kurt Van Dijck
2009-10-11 0:37 ` Marco d'Itri
2009-10-13 15:08 ` dann frazier
2009-10-13 17:13 ` Narendra_K
2009-10-13 17:36 ` dann frazier
2009-10-16 0:32 ` dann frazier
2009-10-16 14:02 ` Narendra_K
2009-10-16 15:20 ` dann frazier
2009-10-16 15:33 ` Ben Hutchings
2009-10-16 15:41 ` dann frazier
2009-10-16 21:40 ` dann frazier
2009-10-19 11:30 ` Narendra_K
2009-10-19 16:14 ` Bryan Kadzban
2009-11-04 14:23 ` Narendra_K
2009-11-06 8:49 ` Marco d'Itri
2009-11-06 22:06 ` Matt Domsch
2009-11-06 22:35 ` Marco d'Itri
2009-11-06 23:17 ` dann frazier
2009-11-09 14:41 ` Narendra_K
2009-11-10 17:23 ` Stephen Hemminger
2009-11-11 6:31 ` Narendra_K
2009-11-06 22:05 ` Domsch, Matt
2009-10-13 19:51 ` Greg KH
2009-10-13 20:00 ` Jordan_Hargrave
2009-10-13 20:19 ` Greg KH
2009-10-13 22:05 ` Matt Domsch
2009-10-13 22:08 ` dann frazier
[not found] <EDA0A4495861324DA2618B4C45DCB3EE5894F6@blrx3m08.blr.amer.dell.com>
2009-10-09 16:04 ` Narendra K
2009-10-09 16:12 ` Stephen Hemminger
2009-10-09 16:25 ` Matt Domsch
[not found] <EDA0A4495861324DA2618B4C45DCB3EE58953F@blrx3m08.blr.amer.dell.com>
2009-10-12 18:07 ` Narendra K
[not found] <EDA0A4495861324DA2618B4C45DCB3EE589541@blrx3m08.blr.amer.dell.com>
2009-10-12 18:47 ` Narendra K
2009-10-12 19:09 ` Greg KH
2009-10-12 19:41 ` Karl O. Pinc
2009-10-13 18:17 ` Dan Williams
2009-10-13 18:56 ` Ben Hutchings
2009-10-12 19:48 ` Matt Domsch
[not found] <EDA0A4495861324DA2618B4C45DCB3EE58964E@blrx3m08.blr.amer.dell.com>
2009-10-28 13:06 ` Narendra K
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1250709985.2874.41.camel@achroite \
--to=bhutchings@solarflare.com \
--cc=Jordan_Hargrave@Dell.com \
--cc=linux-hotplug@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).