From: ebiederm@xmission.com (Eric W. Biederman)
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, equinox@diac24.net,
Linux Containers <containers@lists.osdl.org>
Subject: Re: [PATCH] netns: add /proc/*/net/id symlink
Date: Sat, 21 May 2011 17:15:38 -0700 [thread overview]
Message-ID: <m1vcx3r3o5.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20110521223054.GA3198@p183> (Alexey Dobriyan's message of "Sun, 22 May 2011 01:30:54 +0300")
Adding the containers list.
Alexey Dobriyan <adobriyan@gmail.com> writes:
> On Sat, May 21, 2011 at 08:39:37AM -0700, Eric W. Biederman wrote:
>> Alexey Dobriyan <adobriyan@gmail.com> writes:
>> > * init_net always has id 0
>> > * two netns do not have same id
>> > * id is unsigned integer
>>
>> I don't like this patch because we already have a proc interface
>> that already solves this in production kernels today.
>>
>> - stat is a single syscall
>> - two netns do not have the same id
>> - id is an ino_t.
>
> Yeah, stat /proc/*/net/dev works.
> If you document this, it means we can't change the way ->low_ino is set.
> And we can't do other things inside irregular part of procfs.
Maybe. Certainly there are things that would suggest we need some
fixes to this part of procfs.
> But can we add clean interface once in a while.
I am all for making a clean solution. I don't see a proc file
in in /proc/net that provides a small integer as particularly clean.
It has the classic problem of what namespace are namespaces named in.
It only solves the problem for the network namespace.
So on that level I really like the idea of inode numbers in proc
being the place where we have a name. People generally don't get
confused about inode numbers understanding they are an implementation
detail but they do understand that inode numbers plus filesystem
information can be used to compare files for identity.
So let's skip the fact that /proc/*/net/dev happens to work for a
moment.
For clean interfaces I am in the process of adding /proc/<pid>/ns/net,
/proc/<pid>/ns/ipc, and /proc/<pid>/ns/uts.
If we can make those files inode number be the same if the namespace is
the same like /proc/<pid>/net/dev is today. I think we will have a
clean solution.
Additionally that solution will work for comparing network namespaces
that don't happen to have any processes in them at the moment. Because
fstat works on file descriptors.
With the /proc/<pid>/ns/net file and bind mounts I have solved the
deeper problem of how do we get userspace policy into the naming of
namespaces. With those files and the setns system call I have solved
the other problem of what is a good way to refer to namespaces without
assuming a global name. So once those changes are merged I expect there
to be much less pressure to misuse any kind of identifier we can have.
And if we only make the guarantee about inode consistency for the
/proc/<pid>/ns/FILE files I don't expect it will make maintenance
of procfs any harder than it already is.
Eric
next parent reply other threads:[~2011-05-22 0:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20110521093936.GA3015@p183>
[not found] ` <m11uzsxdty.fsf@fess.ebiederm.org>
[not found] ` <20110521223054.GA3198@p183>
2011-05-22 0:15 ` Eric W. Biederman [this message]
2011-05-23 1:43 ` [PATCH] netns: add /proc/*/net/id symlink David Lamparter
2011-05-23 1:47 ` David Lamparter
2011-06-17 23:31 ` [PATCH 1/2] proc: Generalize proc inode allocation Eric W. Biederman
2011-06-17 23:33 ` [PATCH 2/2] proc: Usable inode numbers for the namespace file descriptors Eric W. Biederman
2011-06-19 23:22 ` David Miller
2011-06-20 16:06 ` Serge E. Hallyn
2011-06-20 19:50 ` Eric W. Biederman
2011-06-19 14:20 ` [PATCH 1/2] proc: Generalize proc inode allocation Serge E. Hallyn
2011-05-23 2:02 ` [PATCH] netns: add /proc/*/net/id symlink Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1vcx3r3o5.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=adobriyan@gmail.com \
--cc=containers@lists.osdl.org \
--cc=davem@davemloft.net \
--cc=equinox@diac24.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox