Linux Container Development
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Christoph Hellwig <hch@infradead.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org,
	containers@lists.osdl.org, sds@tycho.nsa.gov, jmorris@namei.org
Subject: Re: [PATCH 1/6] proc: implement support for automounts in task directories
Date: Tue, 06 Jan 2009 04:20:55 -0800	[thread overview]
Message-ID: <m1vdss1v88.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <20090106092114.GA11877@infradead.org> (Christoph Hellwig's message of "Tue, 6 Jan 2009 04:21:14 -0500")

Christoph Hellwig <hch@infradead.org> writes:

> On Tue, Jan 06, 2009 at 02:32:41AM +0300, Alexey Dobriyan wrote:
>> This is current version of /proc/net as separate file system patchset,
>> rebased, etc. I'll put it into -next again when merge window closes.
>
> I still don't see the point for that.  Why not /proc/nets/<netid> with
> symlinks from /proc/<pid>/net into those?

Simple really.

/proc/nets/<netid> is the other possible viable solution.  Where netid
is some pid value that we assign to the network namespace during
unshare or clone.  While there is precedent of using a pid value
to identify a process group or a session it is a bit of a stretch
to have it cover a namespace.

When I talked it over with Al his preference was to for the
current approach, and it happens to be my preference as well.

It gives more control of naming policy to user space allowing us to
avoid the maintenance pain that is sysfs where user space depends upon
a fixed kernel naming policy (which makes change hard).

It gives us a guarantee that we only have a single dentry tree for
any given network namespace.

It allows us to eventually separate out maintenance of proc/generic
and proc/net, as inherently they have nothing in common.

The only cost of this is that we actually use one of the rare but
fully supported vfs features, on demand submounts.

Beyond that proc has wanted to be several filesystems for ages, and doing
it this way allows us to actually start splitting proc up without breaking
backwards compatibility with out existing user space.

Eric

      reply	other threads:[~2009-01-06 12:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-05 23:32 [PATCH 1/6] proc: implement support for automounts in task directories Alexey Dobriyan
2009-01-05 23:36 ` Alexey Dobriyan
2009-01-06  9:21 ` Christoph Hellwig
2009-01-06 12:20   ` Eric W. Biederman [this message]

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=m1vdss1v88.fsf@frodo.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=adobriyan@gmail.com \
    --cc=containers@lists.osdl.org \
    --cc=hch@infradead.org \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sds@tycho.nsa.gov \
    --cc=viro@zeniv.linux.org.uk \
    /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