Why is interface created through netlink named 'vlan0' and
interface created through old vconfig called 'ethX.YY'.
Seems like the interface should be consistent.
--

[ message continues ]

From: Stephen Hemminger <shemminger@vyatta.com>

I think the netlink scheme is saner, and the idea is to
transition people over to that.

We can't change what vconfig uses, so what Patrick decided
to do is pretty sane if you ask me.
--

[ message continues ]

On Sun, 01 Mar 2009 20:57:02 -0800 (PST)

This is missing:
------------------------------------------------------------------
Subject: vlan: names should be consistent

Vlan's created via netlink should be the same as vlan's created
via older interface. This patches changes is to be consistent.

One could argue this is an API change (it changes behaviour of netlink
interface), but I argue this was a design bug when the netlink interface
to VLAN was added.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>


--- a/net/8021q/vlan.c	2009-03-01 20:54:15.906263870 -0800
+++ b/net/8021q/vlan.c	2009-03-01 20:58:34.290763830 -0800
@@ -292,24 +292,11 @@ out_free_group:
 	return err;
 }
 
-/*  Attach a VLAN device to a mac address (ie Ethernet Card).
- *  Returns 0 if the device was created or a negative error code otherwise.
- */
-static int register_vlan_device(struct net_device *real_dev, u16 vlan_id)
+void vlan_name(char *name, const struct net_device *real_dev, u16 vlan_id)
 {
-	struct net_device *new_dev;
-	struct net *net = dev_net(real_dev);
-	struct vlan_net *vn = net_generic(net, vlan_net_id);
-	char name[IFNAMSIZ];
-	int err;
-
-	if (vlan_id >= VLAN_VID_MASK)
-		return -ERANGE;
-
-	err = vlan_check_real_dev(real_dev, vlan_id);
-	if (err < 0)
-		return err;
-
+	const struct net *net = dev_net(real_dev);
+	const struct vlan_net *vn = net_generic(net, vlan_net_id);
+
 	/* Gotta set up the fields for the device. */
 	switch (vn->name_type) {
 	case VLAN_NAME_TYPE_RAW_PLUS_VID:
@@ -336,6 +323,25 @@ static int register_vlan_device(struct n
 		snprintf(name, IFNAMSIZ, "vlan%.4i", vlan_id);
 	}
 
+}
+
+/*  Attach a VLAN device to a mac address (ie Ethernet Card).
+ *  Returns 0 if the device was created or a negative error code otherwise.
+ */
+static int register_vlan_device(struct net_device *real_dev, u16 vlan_id)
+{
+	struct net_device *new_dev;
+	char name[IFNAMSIZ];
+	int err;
+
+	if (vlan_id >= VLAN_VID_MASK)
+		return -ERANGE;
+
+	err = ...
[ message continues ]

From: Stephen Hemminger <shemminger@vyatta.com>

You can just say you don't think the behavior is
intentional.... :-/

--

[ message continues ]

Indeed, it was intentional not to have these IMO useless naming
schemes when you can simply supply the name of your choice when
creating the interface.

--

[ message continues ]

I don't see the point of this.  The new interface is available
through ip(8) only, vconfig remains unchanged.  So the user is
completely aware that the name may change as he's using a new
command.

In any case, ip(8) allows you to set the name to whatever you
want at creation time.  So for those nostalgics you can still
use ethX.Y through ip.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--

[ message continues ]

Yes but their is no indication as to which interface was just created.
--

[ message continues ]

You should be able to set the name at creation time.

The default is only used if you didn't specify an explicit name.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--

[ message continues ]

Indeed. The kernel also sends notifications, so iproute could print
the generated name if none was specified.
--

[ message continues ]

From: Patrick McHardy <kaber@trash.net>

I considered this issue closed 6 emails ago.

I don't know why Stephen keeps persisting. :-)
--

[ message continues ]

That does seem silly.

ethX.YYYY told you which physical interface and which vlan number it was.

vlan0 tells you nothing useful.

-- 
Len Sorensen
--

[ message continues ]

Even if you have only one ethX?

Jarek P.
--

[ message continues ]

Yes...the old way would tell you the vlan-id regardless of how
many NICs you have, which is useful information for anyone
actually trying to configure two boxes to talk to each other,
or (god forbid), debug someone else's config.

It's true you can specify the vlan-name on creation using 'ip',
which is what I do, so I'm not going to argue Stephen's change
either way..but I do like device names that give more info...

Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

--

[ message continues ]

To make it clear: I don't say vlan0 is better; but IMHO it doesn't
have to be silly or nothing useful either.

Jarek P.
--

[ message continues ]

I guess for Linux it should be ethN.Y.

vlanN is Cisco and other switches behaviour, since they establish vlanN 
interfaces and bridge all vlan with numbers there. In best case they do 
remapping on receive.
So on linux similar alternative of cisco interface vlan100 will be:

ip link add link eth0 type vlan id 100
ip link add link eth1 type vlan id 100
brctl addbr vlan100
brctl addif vlan100 eth0.100
brctl addif vlan100 eth1.100

But on first two steps it creates for me vlan0 and vlan1, which is not very 
informative. I guess interface names should be intuitive, and should help to 
admin to find out for who vlan0 belongs without digging tons of files.

But another point... ip -d link   output is enough useful. I can find out 
easily who is who.
141063: vlan0@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
    link/ether 00:0a:cd:16:82:74 brd ff:ff:ff:ff:ff:ff
    vlan id 100 <REORDER_HDR>
141070: vlan1@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
    link/ether 00:0a:cd:16:82:69 brd ff:ff:ff:ff:ff:ff
    vlan id 100 <REORDER_HDR>

But IMHO ethN.Y more intuitive understandable.

--

[ message continues ]

On Mon, Mar 02, 2009 at 09:23:15PM +0200, Denys Fedoryschenko wrote:

Happily there is a choice. On the other hand, I guess the main question
here is if it's OK to use different defaults depending on a config tool.

Jarek P.
--

[ message continues ]

Admittedly, this part of the rtnl_link interface could be improved.
The names are allocated centrally when unspecified, which imposes
this fixed naming scheme. A simple callback to choose a better
name than just incrementally counting up interfaces types would
allow to at least choose a default name of ethX.xyz or something
similar. I refuse to introduce the selectable naming schemes to
this interface though, this can easily be done in userspace.


--

[ message continues ]

Yes.  What vlan number is vlan0 talking to on ethX?

Not that eth0 ever told you much useful, but at least eth0.0005 told
you something.  I guess vconfig chose the name anyhow before, so no
reason to not continue to let user space take care of what to name it.

-- 
Len Sorensen
--

[ message continues ]

OK, you're right! More info is better. ...How about changing this
silly "eth" thing to something really useful like BSDs do?!

Jarek P.

--

[ message continues ]

The binding is displayed when listing interfaces. This hole
argument is silly, if you want a particular name, just specify
it. The current naming schemes are entirely based on information
that you have to specify anyways.
--

[ message continues ]

On Mon, 02 Mar 2009 22:49:18 +0100

I overlooked the obvious:
 ip li add link eth1 name eth1.44 type vlan id 44

Setting the name overrides.
--

[ message continues ]

Finally someone realizes it :) As stated before, there is room
for improvement, but please no selectable naming schemes when
userspace is ulitimatively responsible anyways :)

--

[ message continues ]

Just for the record, I don't agree with calling "this" argument silly
just like it was with "that" argument. Actually, I think they are
both so "right" that I've changed my mind and think it's great each
tool does it differently...

Jarek P.
--

[ message continues ]

I'm not sure whether I'm supposed to understand this, so I'm going
to respond with something useful unrelated to naming user resources
that every virtual device author should know (and that seems to be
not well known):

Every virtual device bound to a different device should set the
dev->iflink field to the ifindex of the device bound to. This
makes every device related netlink message include this relation.
If the binding is already known at device-creation time and
relevant for the virtuals device's existance, this must be done
in the ->init callback to make sure its already included in the
first netlink creation message to avoid inconsistent information.

This is the also the prefered way device bindings should be
signaled to the kernel, and at least iproute and libnl are
aware of this in both directions. And to get back to the main
point of this discussion:

# ip l l
4: vlan0@dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN
     link/ether 92:2a:4f:ae:dc:29 brd ff:ff:ff:ff:ff:ff
--

[ message continues ]

Yes, very interesting arguments for another disussion... But if we're
talking about naming than you seem to ignore what Lennart, Ben, Denys
and probably Stephen said about their preferred way, and I think it
matters, because if they had problems with understanding this change
I can only imagine what "common users" would say without knowing all
this technical rationale (which IMHO is disputable too - names  are
for people).

Jarek P.
--

[ message continues ]

I like my own naming scheme, and I use it by specifying the name when
creating the vlan using 'ip'.  It would have been nice (IMO) to have the
dev.vid naming be default from the beginning, but since it wasn't, it would
cause more harm than good to change it now.

So, I'm NOT arguing for changing the behaviour, though anything that can
document the features of 'ip' better and make it more obvious you can set
the name upon creation should help people...



-- 
Ben Greear <greearb@candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com


--

[ message continues ]