[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49AC6D24.1030605@trash.net>
Date: Tue, 03 Mar 2009 00:35:00 +0100
From: Patrick McHardy <kaber@...sh.net>
To: Jarek Poplawski <jarkao2@...il.com>
CC: Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
Stephen Hemminger <shemminger@...tta.com>,
netdev@...r.kernel.org
Subject: Re: Vlan interface nuisance
Jarek Poplawski wrote:
> On Mon, Mar 02, 2009 at 10:49:18PM +0100, Patrick McHardy wrote:
>> 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.
>
> 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...
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@...my0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN
link/ether 92:2a:4f:ae:dc:29 brd ff:ff:ff:ff:ff:ff
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists