From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH] net: Add etun driver Date: Wed, 11 Apr 2007 18:15:41 +0200 Message-ID: <461D09AD.9060603@trash.net> References: <1176136628.8459.34.camel@johannes.berg> <461A70A5.8060607@trash.net> <20070409.114402.45491411.davem@davemloft.net> <461A9DF1.8080904@trash.net> <1176150557.8459.47.camel@johannes.berg> <461AD517.2000906@trash.net> <1176239819.10381.10.camel@johannes.berg> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: "Eric W. Biederman" , David Miller , akpm@linux-foundation.org, dim@openvz.org, netdev@vger.kernel.org, jgarzik@pobox.com, containers@lists.osdl.org, kuznet@ms2.inr.ac.ru, shemminger@linux-foundation.org, greearb@candelatech.com To: Johannes Berg Return-path: Received: from stinky.trash.net ([213.144.137.162]:56335 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753179AbXDKQPv (ORCPT ); Wed, 11 Apr 2007 12:15:51 -0400 In-Reply-To: <1176239819.10381.10.camel@johannes.berg> Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Johannes Berg wrote: > On Tue, 2007-04-10 at 02:06 +0200, Patrick McHardy wrote: > > >>Same way as the current RTM_SETLINK message works, but with creating >>a new link in advance. It works fine in other subsystems, so I don't >>see why it would in this case as well. Some subsystems do it in an >>atomic fashion (network schedulers for example), some first create >>the object, then configure it (network classifiers in the non-compat >>cases). In the network device case I suppose the later should work >>fine since a device needs to be set UP in a second action before >>it really does anything. > > > Looking at br_netlink.c it seems that this sort of contradicts why > generic netlink was done, now all the sudden everything that wants to > create new links need its own netlink protocol number, no? No, generic netlink avoids allocating netlink families. br_netlink uses the same netlink family as the other network configuration stuff (NETLINK_ROUTE), but a different rtgen_family (which matches the address families). But you have a valid point, if we want to use this for things like bonding or VLAN that aren't actually address families, we should consider introducing "rtnetlink families" to avoid adding AF_BONDING, AF_8021Q etc.