Eric W. Biederman wrote:
Stephen Hemminger <[email protected]> writes:
Actually, the whole mess would go away if the api for dev_get_by_XXXX hadn't
been changed in the namespace transition. IMHO the interface to
dev_get_by_name()
should not have added a namespace parameter, of the callers in the tree, only
two use a different namespace. So it would have been better to to introduce
dev_get_by_name_ns() with the extra parameter.
As a general rule if you are calling dev_get_by_name and taking an &init_net
parameter that means you code has not yet been converted to actually support
network namespaces.
Not everything can be safely changed at once so we take it by steps. When
the code fully supports network namespaces practically nothing will take
an &init_net parameter. The network namespace parameter will come in
some form from userspace. Either from current or from the network
socket.
Except for boot time initialization I don't know of any cases using
dev_get_by_XXXX that won't need to be modified before the network
namespace work is complete.
I believe I mentioned that this getting the fully network namespace
support was going to take a while and a bunch of patches at the
outset.
Can we get this resolved before 2.6.24 is released? Going back and forth
on API's is just needless frottage.
Sure. We keep the updated dev_get_by_XXXX that takes a network
namespace parameter.
..
And what should code be passing in when "# CONFIG_NET_NS is not set" ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]