On Wed, Oct 22, 2008 at 6:54 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Stephen Hemminger <shemminger@xxxxxxxxxx> writes: >>> 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. >> >> Lots of scripts are starting use /sys for things. It is easier to >> parse /sys/class/net than the output of ifconfig or ip > > Yes. So we need the correct values in /sys/class/net. > > Which is why sysfs and network namespaces do not coexist currently. I definitely agree that "eth0@1" is a bad ide. I know for sure that a relatively large number of system init scripts poke about in /sys/class/net/$IFACE, as well as a number of the system installation scripts. Those scripts include some that my company has written for internal use and others supplied by distributions. Daemons and such mostly use netlink, but for anything written in shell it's much easier to do things like this: for devpath in /sys/class/net/*; do dev="${dev##/sys/class/net/}" case "${dev}" in [....] esac if [ "x${mac}" = "x$(cat ${devpath}/address)" ]; then echo "Found MAC '${mac}': ${dev}" fi done If I wanted to perform similar things with the output of ifconfig, it would involve some much more fragile manual text parsing of the output of the "ip" or "ifconfig" commands. And sometimes the "ifconfig" command is outright wrong. If you have an interface name longer than 7 characters or so then some versions of ifconfig will truncate it internally and display garbage. While the "show only the root namespace" interim solution is problematic for processes in network namespaces, I think it's more important not to break things for admin tools in the root namespace. Cheers, Kyle Moffett _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers