Re: [PATCH 0/4][RFC] netns: sysfs: add a netns suffix to net device sysfs entries
From: Eric W. Biederman
Date: Wed Oct 22 2008 - 17:04:51 EST
"Serge E. Hallyn" <serue@xxxxxxxxxx> writes:
> Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx):
>> Benjamin Thery <benjamin.thery@xxxxxxxx> writes:
>> > Support for network namespaces in mainline is pretty complete for
>> > some time now, but there is still this issue with sysfs that prevents
>> > more people to use it easily.
>> Ben your patchset is completely inappropriate.
>> Temporarily adding elements to the ABI that we intend to remove
>> is not a proper solution to this problem.
>> That user space visible ida you add is a namespace identifier that breaks
>> nested containers and migration. It is very very very wrong.
> I disagree (not surprising :) completely. The well-known userspace
> tools (ifconfig, ip, etc) will not see the lo@1, they'll see lo.
> Userspace in a container can either umount /sys completely, or do
The well-known user space tools don't use /sys at all. Modern
network tools use rtnetlink (ip) old network tools use /proc/net.
Very few things actually use /sys and for those things lo@1 or
eth0@1 are completely useless except for implementing a FUSE
mock up of sysfs. But you don't need anything in sysfs to do
that as all of the interesting information is available through
/proc/net or rtnetlink.
> mount -t tmpfs none /sys/class/net
> mount --bind /sys/devices/virtual/net/lo@1 /sys/class/net/lo
> if they really want to, in which case only their view
> of /sys/devices/virtual/net would be different.
> Eric, would you hate this less if it was under some
> config variable?
No. ABI decisions are almost certainly irreversible.
If we need an immediate hack please see the patch I sent
in follow up. We can achieve everything Ben is doing by simply
keeping virtual devices out of the kobject tree. Keeping them
from showing up in sysfs.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/