[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1k5nuw7p6.fsf@ebiederm.dsl.xmission.com>
Date: Tue, 04 Dec 2007 13:01:09 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Ben Greear <greearb@...delatech.com>
Cc: Patrick McHardy <kaber@...sh.net>,
Stephen Hemminger <shemminger@...ux-foundation.org>,
Mark Lord <lkml@....ca>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, containers@...ts.osdl.org,
David Miller <davem@...emloft.net>
Subject: Re: namespace support requires network modules to say "GPL"
Ben Greear <greearb@...delatech.com> writes:
> I have a module that has a collection of 2-port bridges. These bridges are used
> for emulation
> purposes (somewhat similar to netem's feature set). Each bridge is logically
> independent
> of the others. To set up a bridge, I do something like:
>
> echo add_my_bridge my_br1 eth0 eth1 > /proc/net/foo/config
Interesting. Currently /proc/net is also per network namespace.
So normally I would say just call get_proc_net from inside your
proc handler and all would be well.
At another location in /proc (not under /proc/net) I would just do:
dev_get_by_name(current->nsproxy->net_ns, "ethX");
I would probably be paranoid and grab current->nsproxy->net_ns
when the file was opened and put it when the file was closed
just to ensure that if someone opened it and then passed
the file descriptor to someone else there were not any
weird little races. But I don't expect that is a problem
in your case.
> Personally, it seems useful for my module to be able to have eth0 in one
> namespace
> and eth1 in another, but I won't complain if they both have to be in the same
> namespace
> or even just in the default namespace due to GPL symbol issues.
It probably is easiest to move the devices after your module has
bridged them.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists