Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756328AbYJVVEv (ORCPT ); Wed, 22 Oct 2008 17:04:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752021AbYJVVEf (ORCPT ); Wed, 22 Oct 2008 17:04:35 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:46659 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757429AbYJVVEd (ORCPT ); Wed, 22 Oct 2008 17:04:33 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "Serge E. Hallyn" Cc: Benjamin Thery , netdev , Dave Miller , Greg Kroah-Hartman , Al Viro , Daniel Lezcano , linux-kernel@vger.kernel.org, Tejun Heo , Denis Lunev , Linux Containers References: <20081022152144.351965414@theryb.frec.bull.fr> <20081022203045.GA4633@us.ibm.com> Date: Wed, 22 Oct 2008 14:01:59 -0700 In-Reply-To: <20081022203045.GA4633@us.ibm.com> (Serge E. Hallyn's message of "Wed, 22 Oct 2008 15:30:45 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-XM-SPF: eid=;;;mid=;;;hst=mx04.mta.xmission.com;;;ip=24.130.11.59;;;frm=ebiederm@xmission.com;;;spf=neutral X-SA-Exim-Connect-IP: 24.130.11.59 X-SA-Exim-Rcpt-To: too long (recipient list exceeded maximum allowed size of 128 bytes) X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;"Serge E. Hallyn" X-Spam-Relay-Country: X-Spam-Report: * -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * -0.2 BAYES_40 BODY: Bayesian spam probability is 20 to 40% * [score: 0.3864] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 XM_SPF_Neutral SPF-Neutral Subject: Re: [PATCH 0/4][RFC] netns: sysfs: add a netns suffix to net device sysfs entries X-SA-Exim-Version: 4.2.1 (built Thu, 07 Dec 2006 04:40:56 +0000) X-SA-Exim-Scanned: Yes (on mx04.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2101 Lines: 56 "Serge E. Hallyn" writes: > Quoting Eric W. Biederman (ebiederm@xmission.com): >> Benjamin Thery 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_SYSFS_NETNS_HACK > > 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. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/