[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <461B6B22.3090009@trash.net>
Date: Tue, 10 Apr 2007 12:46:58 +0200
From: Patrick McHardy <kaber@...sh.net>
To: Johannes Berg <johannes@...solutions.net>
CC: "Eric W. Biederman" <ebiederm@...ssion.com>,
David Miller <davem@...emloft.net>, akpm@...ux-foundation.org,
dim@...nvz.org, netdev@...r.kernel.org, jgarzik@...ox.com,
containers@...ts.osdl.org, kuznet@....inr.ac.ru,
shemminger@...ux-foundation.org, greearb@...delatech.com
Subject: Re: [PATCH] net: Add etun driver
Johannes Berg wrote:
> On Tue, 2007-04-10 at 11:52 +0200, Patrick McHardy wrote:
>
>
>>Without having thought much about it yet, roughly like this:
>>
>>- driver receives RTM_NEWLINK message (under rtnl)
>>- driver allocates new device
>>- driver initializes device based on content of RTM_NEWLINK message
>>- driver returns
>
>
> Sounds good to me, but where's the advantage over something that isn't
> generic if RTM_NEWLINK contains totally different things depending on
> the subsystem like wireless where it'd have to contain the hardware
> identifier?
Not totally different, so far I think we should use the same attributes
as for RTM_SETLINK messages and include the device-specific stuff in
IFLA_PROTINFO, which is symetric to what the kernel sends in RTM_NETLINK
messages (see br_netlink.c for an example). The easiest case would be an
empty IFLA_PROTINFO attribute, which would simply create a device
without any configuration.
The main advantage that we don't get more weird sysfs/proc/ioctl based
interfaces and use the same interface that is used for all other network
configuration, which f.e. will allow to add support for all software
devices to iproute without much effort, so you don't need 30 different
tools for configuring the different software device types anymore.
Additionally we get atomic setup/dumps and extensibility.
-
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