diff options
author | Eric W. Biederman <ebiederm@xmission.com> | 2008-10-27 17:51:47 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2008-10-27 17:51:47 -0700 |
commit | 3891845e1ef6e6807075d4241966b26f6ecb0a5c (patch) | |
tree | 3ccf11ecce77d13d929b4f17b583e05bb3ffa495 /net/Kconfig | |
parent | 7c510e4b730a92cecf94ada45c989d8be0200d47 (diff) | |
download | linux-3891845e1ef6e6807075d4241966b26f6ecb0a5c.tar.gz linux-3891845e1ef6e6807075d4241966b26f6ecb0a5c.tar.bz2 linux-3891845e1ef6e6807075d4241966b26f6ecb0a5c.zip |
netns: Coexist with the sysfs limitations v2
To make testing of the network namespace simpler allow
the network namespace code and the sysfs code to be
compiled and run at the same time. To do this only
virtual devices are allowed in the additional network
namespaces and those virtual devices are not placed
in the kobject tree.
Since virtual devices don't actually do anything interesting
hardware wise that needs device management there should
be no loss in keeping them out of the kobject tree and
by implication sysfs. The gain in ease of testing
and code coverage should be significant.
Changelog:
v2: As pointed out by Benjamin Thery it only makes sense to call
device_rename in the initial network namespace for now.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Benjamin Thery <benjamin.thery@bull.net>
Tested-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Daniel Lezcano <dlezcano@fr.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/Kconfig')
-rw-r--r-- | net/Kconfig | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/net/Kconfig b/net/Kconfig index d789d79551ae..8c3d97ca0d96 100644 --- a/net/Kconfig +++ b/net/Kconfig @@ -27,7 +27,7 @@ menu "Networking options" config NET_NS bool "Network namespace support" default n - depends on EXPERIMENTAL && !SYSFS && NAMESPACES + depends on EXPERIMENTAL && NAMESPACES help Allow user space to create what appear to be multiple instances of the network stack. |