| Message ID | tkrat.21c425cc195510c9@s5r6.in-berlin.de |
|---|---|
| State | Rejected, archived |
| Delegated to: | David Miller |
| Headers | show |
Thu, May 21, 2009 at 03:29:10PM CEST, stefanr@s5r6.in-berlin.de wrote: >Change the initial name of IP-over-1394 networking interfaces from >"eth[0-9]+" to "firewire[0-9]+". > >This should have been done years ago for the reason mentioned in the >inline comment. The naming issue basically prevented acceptance of >IP networking over 1394 on Linux. > >The future IP-over1394 driver in the newer alternative firewire driver >stack will use the "firewire%d" format from the start while "eth%d" will >no longer be used in the new driver. > >Necessary changes in userland: > >People who use the eth1394 driver either have to update their network >configuration (or instead perhaps respecpective udev interface renaming >rules) to the new names, or add > > options eth1394 firewire_interface_name=N > >to /etc/modprobe.conf or /etc/modprobe.d/whatever if they really prefer >the old names. > >Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> >--- > drivers/ieee1394/eth1394.c | 23 ++++++++++++++++++++++- > 1 file changed, 22 insertions(+), 1 deletion(-) > >Index: linux/drivers/ieee1394/eth1394.c >=================================================================== >--- linux.orig/drivers/ieee1394/eth1394.c >+++ linux/drivers/ieee1394/eth1394.c >@@ -146,6 +146,25 @@ MODULE_DESCRIPTION("IEEE 1394 IPv4 Drive > MODULE_LICENSE("GPL"); > > /* >+ * Legacy option: Choose between "eth%d" (old) and "firewire%d" (new, default) >+ * as name template of eth1304's networking interfaces. >+ * >+ * eth1394 used to set "eth[0-9]+" as the initial name of an IP-over-1394 >+ * networking interface. This caused trouble for users and admins since >+ * it is indistinguishable from Ethernet drivers' interfaces. >+ * >+ * From Linux 2.6.31 on, "eth[0-9]+" remains only an option which can be >+ * activated by setting the following module parameter to N. The default >+ * name format is "firewire[0-9]+" now. This way, people will immediately >+ * recognize what kind of networking interface this is, and no mix-ups >+ * with Ethernet interface configurations will happen anymore. >+ */ >+static int firewire_interface_name = 1; >+module_param(firewire_interface_name, bool, S_IRUGO | S_IWUSR); >+MODULE_PARM_DESC(firewire_interface_name, "use 'firewire' (= Y, default) or " >+ "'eth' (= N, legacy option) as name prefix of interfaces"); >+ >+/* > * The max_partial_datagrams parameter is the maximum number of fragmented > * datagrams per node that eth1394 will keep in memory. Providing an upper > * bound allows us to limit the amount of memory that partial datagrams >@@ -595,7 +614,9 @@ static void ether1394_add_host(struct hp > return; > } > >- dev = alloc_netdev(sizeof(*priv), "eth%d", ether1394_init_dev); >+ dev = alloc_netdev(sizeof(*priv), >+ firewire_interface_name ? "firewire%d" : "eth%d", Isn't "firewire" too long? Wouldn't it be better to use some addrev like other devices do? "fw"? To safe some time and possible troubles with typos. Just a thought. Jirka >+ ether1394_init_dev); > if (dev == NULL) { > ETH1394_PRINT_G(KERN_ERR, "Out of memory\n"); > goto out; > >-- >Stefan Richter >-=====-==--= -=-= =-=-= >http://arcgraph.de/sr/ > >-- >To unsubscribe from this list: send the line "unsubscribe netdev" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Jiri Pirko wrote: > Thu, May 21, 2009 at 03:29:10PM CEST, stefanr@s5r6.in-berlin.de wrote: >> - dev = alloc_netdev(sizeof(*priv), "eth%d", ether1394_init_dev); >> + dev = alloc_netdev(sizeof(*priv), >> + firewire_interface_name ? "firewire%d" : "eth%d", > > Isn't "firewire" too long? Wouldn't it be better to use some addrev like other > devices do? "fw"? To safe some time and possible troubles with typos. > > Just a thought. Usually I prefer brevity too. Alas, it may not be clear to many people what "fw" is supposed to mean. People might associate it with, let's say, "firewall" before "firewire" when they deal with networking. However, more opinions on this are welcome. As for practical length restrictions: The kernel's networking core requires that these names fit into 15 characters plus trailing \0. I don't have an idea whether there are userland components which have even tighter restrictions. Does anybody know of potential trouble in networking tools if interface names are 9 or 10 characters long? BTW, FreeBSD uses the name fwip%d AFAIK, and OS X just uses fw%d. (But basically nobody is ever confronted with this interface name on OS X because Apple's network config GUIs don't use them.) FWIW, ifconfig's output is still nicely aligned after this change. :-) -------------------- 8< -------------------- eth0 Link encap:Ethernet HWaddr 00:23:54:91:8a:2b inet addr:192.168.0.42 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:12350891 errors:0 dropped:0 overruns:0 frame:0 TX packets:13934958 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:7376420576 (6.8 GiB) TX bytes:8066580858 (7.5 GiB) Interrupt:28 Base address:0xa000 firewire0 Link encap:UNSPEC HWaddr 08-00-28-56-00-00-31-9B-00-00-00-00-00-00-00-00 inet addr:10.10.222.42 Bcast:10.10.222.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:72 (72.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2865 errors:0 dropped:0 overruns:0 frame:0 TX packets:2865 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1292569 (1.2 MiB) TX bytes:1292569 (1.2 MiB)
On Thu, May 21, 2009 at 16:31, Stefan Richter <stefanr@s5r6.in-berlin.de> wrote: > Usually I prefer brevity too. Alas, it may not be clear to many people what > "fw" is supposed to mean. People might associate it with, let's say, > "firewall" before "firewire" when they deal with networking. However, more > opinions on this are welcome. Yeah, common one is also "firmware". I think "firewire" is fine. > As for practical length restrictions: The kernel's networking core requires > that these names fit into 15 characters plus trailing \0. I don't have an > idea whether there are userland components which have even tighter > restrictions. > > Does anybody know of potential trouble in networking tools if interface > names are 9 or 10 characters long? I don't think so, stuff at the tools level usually works flawlessly with "eth0_rename_ren" devices, when things went wrong with renaming the devices. :) Kay -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Stefan Richter <stefanr@s5r6.in-berlin.de> Date: Thu, 21 May 2009 15:29:10 +0200 (CEST) > Change the initial name of IP-over-1394 networking interfaces from > "eth[0-9]+" to "firewire[0-9]+". > > This should have been done years ago for the reason mentioned in the > inline comment. The naming issue basically prevented acceptance of > IP networking over 1394 on Linux. > > The future IP-over1394 driver in the newer alternative firewire driver > stack will use the "firewire%d" format from the start while "eth%d" will > no longer be used in the new driver. > > Necessary changes in userland: > > People who use the eth1394 driver either have to update their network > configuration (or instead perhaps respecpective udev interface renaming > rules) to the new names, or add > > options eth1394 firewire_interface_name=N > > to /etc/modprobe.conf or /etc/modprobe.d/whatever if they really prefer > the old names. > > Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> I think the basis for this patch is completely bogus. Device names are just that, names. If you want to know "what it is" or "where it is" you use tools to determine that information. If you make ethtool's get info command return something useful, then the user can see that it's a firewire interface and act accordingly, as can sophisticated confiruation applications. I am completely against this patch. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller wrote: > From: Stefan Richter <stefanr@s5r6.in-berlin.de> > Date: Thu, 21 May 2009 15:29:10 +0200 (CEST) >> Change the initial name of IP-over-1394 networking interfaces from >> "eth[0-9]+" to "firewire[0-9]+". ... > I think the basis for this patch is completely bogus. > > Device names are just that, names. If you want to know "what it is" > or "where it is" you use tools to determine that information. > > If you make ethtool's get info command return something useful, > then the user can see that it's a firewire interface and act > accordingly, as can sophisticated confiruation applications. > > I am completely against this patch. Ethtool shows: driver: eth1394 version: firmware-version: bus-info: ieee1394 And the sysfs representations of the netdevices have an fw-host* device in the parent device chain. I agree that userland should read less into names as they are handed out by the kernel. I am also aware that it depends on the use case what naming scheme can be considered useful, hence userspace needs to give his own names anyway, regardless of how the kernel named it. But I mildly disagree with the notion that the kernel can't start off with more qualification of the names than merely ensuring their uniqueness. Or the other way around: Even an entirely meaningless prefix would be better than "eth..", or no prefix if that's possible, because eth suspiciously sounds like Ethernet with which the misnamed RFC 2734 driver eth1394 has very little to do. However, how mild my disagreement is should be apparent from the fact that I didn't bother to suggest changing it before now, in 2009. :-)
From: Stefan Richter <stefanr@s5r6.in-berlin.de> Date: Thu, 21 May 2009 22:13:50 +0200 > But I mildly disagree with the notion that the kernel can't start off > with more qualification of the names than merely ensuring their > uniqueness. Or the other way around: Even an entirely meaningless > prefix would be better than "eth..", or no prefix if that's possible, > because eth suspiciously sounds like Ethernet with which the misnamed > RFC 2734 driver eth1394 has very little to do. Even the driver source file is named "ethXXX"! All of the macros in the driver are named ETH*. The eth1394hdr looks eerily similar to a real ethernet header except that it lacks a source MAC address. It's addressing information plus a 16-bit (wow, why that size huh?) protocol field. A lot like ethernet. At the very least, it's related and similar. So there is really nothing inappropriate about eth* naming. > However, how mild my disagreement is should be apparent from the fact > that I didn't bother to suggest changing it before now, in 2009. :-) You have more to lose by changing this now (breaking existing systems, and yes I did see the hack workaround you posted) instead of fixing userspace to make whatever indications you deem appropriate. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller wrote: > From: Stefan Richter <stefanr@s5r6.in-berlin.de> > Date: Thu, 21 May 2009 22:13:50 +0200 > >> But I mildly disagree with the notion that the kernel can't start off >> with more qualification of the names than merely ensuring their >> uniqueness. Or the other way around: Even an entirely meaningless >> prefix would be better than "eth..", or no prefix if that's possible, >> because eth suspiciously sounds like Ethernet with which the misnamed >> RFC 2734 driver eth1394 has very little to do. > > Even the driver source file is named "ethXXX"! All of the macros > in the driver are named ETH*. The eth1394hdr looks eerily similar > to a real ethernet header except that it lacks a source MAC > address. It's addressing information plus a 16-bit (wow, why that > size huh?) protocol field. A lot like ethernet. Sure, because 1. eth1394 was initially written with an eye on how Linux Ethernet drivers look like (for quite a while it didn't implement RFC 2734), 2. by nature, RFC 2734 as an IP encapsulation can't be very different from Ethernet. As it happens, RFC 2734 indeed reuses a certain 16 bits wide protocol type field in its encapsulation header, with familar values such as 0x0800. [BTW, the rest of the struct eth1394hdr is not the encapsulation header which goes out to the wire, it's only used internally by the driver. The real on-the-wire headers are 20...28 bytes wide, depending on transaction mode and link fragmentation, and there are 4 bytes trailing data CRC.]
Christian Kujau wrote at LKML: > If the patch will be accepted at all and it's not too late to ask: I'd > vote for fw%d as well, "firefire" just looks too long, for me at least. I think I'll leave the driver as it is. As I just noticed, we would lose interface renaming by udev. From udev/extras/rule_generator/75-persistent-net-generator.rules: # device name whitelist KERNEL!="eth*|ath*|wlan*[0-9]|msh*|ra*|sta*|ctc*|lcs*|hsi*", GOTO="persistent_net_generator_end" Besides, if we can we should avoid fw%d because this will clash with udev rules which match KERNEL=="fw*", as in udev/rules/redhat/40-redhat.rules.
On Sonntag, 24. Mai 2009, Stefan Richter wrote: > Christian Kujau wrote at LKML: > > If the patch will be accepted at all and it's not too late to ask: I'd > > vote for fw%d as well, "firefire" just looks too long, for me at least. > > I think I'll leave the driver as it is. > As I just noticed, we would lose interface renaming by udev. > From udev/extras/rule_generator/75-persistent-net-generator.rules: > > # device name whitelist > KERNEL!="eth*|ath*|wlan*[0-9]|msh*|ra*|sta*|ctc*|lcs*|hsi*", > GOTO="persistent_net_generator_end" > > Besides, if we can we should avoid fw%d because this will clash with > udev rules which match KERNEL=="fw*", as in > udev/rules/redhat/40-redhat.rules. I suggest a subsystem match here, or generally some SUBSYSTEM!="net", GOTO="end_of_file" around almost all rule files that should not match on network interfaces, as users can rename them to almost all crazy names. @Kay: Perhaps it could simplify some rulesets to have a special jump target or option to skip entiere rules files. Regards Matthias -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Matthias Schwarzott wrote: > On Sonntag, 24. Mai 2009, Stefan Richter wrote: >> Besides, if we can we should avoid fw%d because this will clash with >> udev rules which match KERNEL=="fw*", as in >> udev/rules/redhat/40-redhat.rules. > > I suggest a subsystem match here, or generally some > SUBSYSTEM!="net", GOTO="end_of_file" > around almost all rule files that should not match on network interfaces, as > users can rename them to almost all crazy names. > > @Kay: Perhaps it could simplify some rulesets to have a special jump target or > option to skip entiere rules files. Right... Luckily, 75-persistent-net-generator.rules already has a big SUBSYSTEM!="net", GOTO="persistent_net_generator_end" around everything. Also, "fw*" devices related rules which I'll submit RSN will have SUBSYSTEM=="firewire" prefixes.
On Mon, May 25, 2009 at 10:33, Matthias Schwarzott <zzam@gentoo.org> wrote: > On Sonntag, 24. Mai 2009, Stefan Richter wrote: >> Christian Kujau wrote at LKML: >> > If the patch will be accepted at all and it's not too late to ask: I'd >> > vote for fw%d as well, "firefire" just looks too long, for me at least. >> >> I think I'll leave the driver as it is. >> As I just noticed, we would lose interface renaming by udev. >> From udev/extras/rule_generator/75-persistent-net-generator.rules: >> >> # device name whitelist >> KERNEL!="eth*|ath*|wlan*[0-9]|msh*|ra*|sta*|ctc*|lcs*|hsi*", >> GOTO="persistent_net_generator_end" >> >> Besides, if we can we should avoid fw%d because this will clash with >> udev rules which match KERNEL=="fw*", as in >> udev/rules/redhat/40-redhat.rules. > > I suggest a subsystem match here, or generally some > SUBSYSTEM!="net", GOTO="end_of_file" > around almost all rule files that should not match on network interfaces, as > users can rename them to almost all crazy names. > > @Kay: Perhaps it could simplify some rulesets to have a special jump target or > option to skip entiere rules files. Not sure, if Fedora is using this rule file, there seems a lot of old stuff in it. But the rule should be ignored for device without a device node, when SYMLINK is given in the rule. Kay -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: linux/drivers/ieee1394/eth1394.c =================================================================== --- linux.orig/drivers/ieee1394/eth1394.c +++ linux/drivers/ieee1394/eth1394.c @@ -146,6 +146,25 @@ MODULE_DESCRIPTION("IEEE 1394 IPv4 Drive MODULE_LICENSE("GPL"); /* + * Legacy option: Choose between "eth%d" (old) and "firewire%d" (new, default) + * as name template of eth1304's networking interfaces. + * + * eth1394 used to set "eth[0-9]+" as the initial name of an IP-over-1394 + * networking interface. This caused trouble for users and admins since + * it is indistinguishable from Ethernet drivers' interfaces. + * + * From Linux 2.6.31 on, "eth[0-9]+" remains only an option which can be + * activated by setting the following module parameter to N. The default + * name format is "firewire[0-9]+" now. This way, people will immediately + * recognize what kind of networking interface this is, and no mix-ups + * with Ethernet interface configurations will happen anymore. + */ +static int firewire_interface_name = 1; +module_param(firewire_interface_name, bool, S_IRUGO | S_IWUSR); +MODULE_PARM_DESC(firewire_interface_name, "use 'firewire' (= Y, default) or " + "'eth' (= N, legacy option) as name prefix of interfaces"); + +/* * The max_partial_datagrams parameter is the maximum number of fragmented * datagrams per node that eth1394 will keep in memory. Providing an upper * bound allows us to limit the amount of memory that partial datagrams @@ -595,7 +614,9 @@ static void ether1394_add_host(struct hp return; } - dev = alloc_netdev(sizeof(*priv), "eth%d", ether1394_init_dev); + dev = alloc_netdev(sizeof(*priv), + firewire_interface_name ? "firewire%d" : "eth%d", + ether1394_init_dev); if (dev == NULL) { ETH1394_PRINT_G(KERN_ERR, "Out of memory\n"); goto out;
Change the initial name of IP-over-1394 networking interfaces from "eth[0-9]+" to "firewire[0-9]+". This should have been done years ago for the reason mentioned in the inline comment. The naming issue basically prevented acceptance of IP networking over 1394 on Linux. The future IP-over1394 driver in the newer alternative firewire driver stack will use the "firewire%d" format from the start while "eth%d" will no longer be used in the new driver. Necessary changes in userland: People who use the eth1394 driver either have to update their network configuration (or instead perhaps respecpective udev interface renaming rules) to the new names, or add options eth1394 firewire_interface_name=N to /etc/modprobe.conf or /etc/modprobe.d/whatever if they really prefer the old names. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> --- drivers/ieee1394/eth1394.c | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-)