From: "Eric W. Biederman" <ebiederm@xmission.com>
To: sukadev@us.ibm.com
Cc: Andrew Morton <akpm@osdl.org>,
serue@us.ibm.com, matthltc@us.ibm.com, hpa@zytor.com,
Pavel Emelyanov <xemul@openvz.org>,
Containers <containers@lists.osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] Helper patches for PTY namespaces
Date: Sat, 12 Apr 2008 12:06:55 -0700 [thread overview]
Message-ID: <1208027215.28187.17.camel@x61.ebiederm.org> (raw)
In-Reply-To: <20080412172933.GA19295@us.ibm.com>
On Sat, 2008-04-12 at 10:29 -0700, sukadev@us.ibm.com wrote:
> Some simple helper patches to enable implementation of multiple PTY
> (or device) namespaces.
>
> [PATCH 1/4]: Propagate error code from devpts_pty_new
> [PATCH 2/4]: Factor out PTY index allocation
> [PATCH 3/4]: Move devpts globals into init_pts_ns
> [PATCH 3/4]: Enable multiple mounts of /dev/pts
>
> This patchset is based on earlier versions developed by Serge Hallyn
> and Matt Helsley.
Suka Stop.
The first two patches appear to just be cleanups and as such should be
able to stand on their own. Mentioning that you found these
opportunities while working on your pts namespace is fine. Justifying
the cleanups this way is not.
When you mentioned you intended to just resend the cleanups this is not
at all what I thought you were about. So please just get the first two
patches in a form that stands by themselves.
The pts namespace as designed is not acceptable.
The problem you are trying to solve with the pts namespace is real.
So what we need is a device namespace and possibly and incremental path
to get there. A device namespace would abstract the device number to
device mapping for all devices. A safe incremental path would disable
all device number to device mappings for process in that namespace. So
all functionality would be gone, then it would enable certain mappings
and certain pieces of the functionality if the code in the kernel is not
clean enough that we can do it all in one go.
We need to see that path. Only then can we take patches that add
namespace specific goo. The pattern I am proposing has worked quite
well for the network namespace. Meanwhile the uid namespace which
follows the pattern you seem to be following now seems does not look to
be completed any time soon.
So send your clean up patches and then let's architect this thing so we
are really talking about a namespace. Then we can update devpts to
capture the device namespace on mount and do it's work in a namespace
specific manner.
Eric
next prev parent reply other threads:[~2008-04-12 19:07 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-12 17:29 sukadev
2008-04-12 17:32 ` [PATCH 1/4]: Propagate error code from devpts_pty_new sukadev
2008-04-12 17:32 ` [PATCH 2/4]: Factor out PTY index allocation sukadev
2008-04-12 17:33 ` [PATCH 3/4]: Move devpts globals into init_pts_ns sukadev
2008-04-12 17:34 ` [PATCH 4/4]: Enable multiple mounts of /dev/pts sukadev
2008-04-12 18:09 ` [PATCH 0/4] Helper patches for PTY namespaces H. Peter Anvin
2008-04-12 18:35 ` Al Viro
2008-04-12 18:54 ` Multiple instances of devpts H. Peter Anvin
2008-04-12 19:15 ` Eric W. Biederman
2008-04-12 19:24 ` H. Peter Anvin
2008-04-12 19:30 ` H. Peter Anvin
2008-04-12 19:06 ` Eric W. Biederman [this message]
2008-04-13 0:59 ` [PATCH 0/4] Helper patches for PTY namespaces Serge E. Hallyn
2008-08-01 18:12 ` Per-instance devpts H. Peter Anvin
2008-08-01 19:23 ` Dave Hansen
2008-08-01 19:35 ` Al Viro
2008-08-01 19:37 ` H. Peter Anvin
[not found] ` <f73f7ab80808020004j15b0d0e5x5fa911242641b34d@mail.gmail.com>
2008-08-02 7:06 ` Kyle Moffett
2008-08-02 15:33 ` H. Peter Anvin
2008-08-02 8:54 ` Bastian Blank
2008-08-03 5:08 ` sukadev
2008-08-03 11:31 ` H. Peter Anvin
2008-08-03 12:04 ` Alan Cox
2008-08-03 17:46 ` sukadev
2008-08-03 17:54 ` Alan Cox
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=1208027215.28187.17.camel@x61.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@osdl.org \
--cc=containers@lists.osdl.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthltc@us.ibm.com \
--cc=serue@us.ibm.com \
--cc=sukadev@us.ibm.com \
--cc=xemul@openvz.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
all inboxes | Powered by JetHome®