[PATCH] ieee1394: eth1394: use "firewire%d" instead of "eth%d" as interface name

[PATCH] ieee1394: eth1394: use "firewire%d" instead of "eth%d" as interface name

[Stefan Richter]

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",
+			   ether1394_init_dev);
 	if (dev == NULL) {
 		ETH1394_PRINT_G(KERN_ERR, "Out of memory\n");
 		goto out;

-- 
Stefan Richter
-=====-==--= -=-= =-=-=
http://arcgraph.de/sr/


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 

Re: [PATCH] ieee1394: eth1394: use "firewire%d" instead of "eth%d" as interface name

[Jiri Pirko]

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

Re: [PATCH] ieee1394: eth1394: use "firewire%d" instead of "eth%d" as interface name

[Stefan Richter]

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)
-- 
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 

Re: [PATCH] ieee1394: eth1394: use "firewire%d" instead of "eth%d" as interface name

[Kay Sievers]

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 linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ieee1394: eth1394: use "firewire%d" instead of "eth%d" as interface name

[Stefan Richter]

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.
-- 
Stefan Richter
-=====-==--= -=-= ==---
http://arcgraph.de/sr/

Re: [PATCH] ieee1394: eth1394: use "firewire%d" instead of "eth%d" as interface name

[Matthias Schwarzott]

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

Re: [PATCH] ieee1394: eth1394: use "firewire%d" instead of "eth%d" as interface name

[Stefan Richter]

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.
-- 
Stefan Richter
-=====-==--= -=-= ==--=
http://arcgraph.de/sr/

Re: [PATCH] ieee1394: eth1394: use "firewire%d" instead of "eth%d" as interface name

[Kay Sievers]

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 linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ieee1394: eth1394: use "firewire%d" instead of "eth%d" as interface name

[David Miller]

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.

Re: [PATCH] ieee1394: eth1394: use "firewire%d" instead of "eth%d" as interface name

[Stefan Richter]

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. :-)
-- 
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 

Re: [PATCH] ieee1394: eth1394: use "firewire%d" instead of "eth%d" as interface name

[David Miller]

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.

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 

Re: [PATCH] ieee1394: eth1394: use "firewire%d" instead of "eth%d" as interface name

[Stefan Richter]

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.]
-- 
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/