[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1222509685.3798.59.camel@johannes.berg>
Date: Sat, 27 Sep 2008 12:01:25 +0200
From: Johannes Berg <johannes@...solutions.net>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: linux-wireless <linux-wireless@...r.kernel.org>,
netdev <netdev@...r.kernel.org>, Jouni Malinen <j@...fi>
Subject: wireless vs. network namespaces (part II)
Eric,
You wrote, over a year ago:
> 2) Advanced routing. Where someone is doing some weird thing like
> testing sending packets and receiving them on the same machine.
and I was just thinking of doing exactly that :)
When looking into it, though, I noticed that you can generate some
breakage with wireless and network namespaces: you can move a wireless
netdev to a different namespace and then things will break down because
we internally use init_net to find it.
What I'd like to do in wireless is not allow moving netdevs between
namespaces, but rather move entire hardware devices between namespaces,
I see little value and great pain in trying to support virtual
interfaces from a single physical device showing up in different
namespaces, but I do see value in binding a physical device (wiphy) to a
namespace.
As far as I understand, to disallow moving them, I should set the
NETIF_F_NETNS_LOCAL flag on all devices, although that is sort of a
misnomer then because I'd be using it to indicate 'cannot switch
namespace'.
To really support this though, it seems we need to
* put the wiphy list into struct net (this is currently a simple
list_head, no fancy hashing)
* give each struct wiphy a backpointer to the struct net, like netdev
in the netdev struct
* ensure that all netdevs created for this wiphy will have the right
netns.
The latter part I'm unsure on, alloc_netdev_mq seems to always use
init_net so I can't put them into the right namespace to start with, but
because they're all "in there together" I can't allow switching
namespaces either.. Ideas?
johannes
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists