mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: sukadev@us.ibm.com, 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 19:59:36 -0500	[thread overview]
Message-ID: <20080413005936.GA21021@sergelap.austin.ibm.com> (raw)
In-Reply-To: <1208027215.28187.17.camel@x61.ebiederm.org>

Quoting Eric W. Biederman (ebiederm@xmission.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.

It took me a minute to figure out what you were offended by, but I see,
the patches still introduce a "pts ns", which shouldn't exist at all.

> 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.

(you know perfectly well that we're holding off on any further real
uidns work until netns is complete and you have time to partake in the
design - it wouldn't be any fun without you :)

> 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.

Sounds reasonable to me.

thanks,
-serge

  reply	other threads:[~2008-04-13  1:00 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 ` [PATCH 0/4] Helper patches for PTY namespaces Eric W. Biederman
2008-04-13  0:59   ` Serge E. Hallyn [this message]
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=20080413005936.GA21021@sergelap.austin.ibm.com \
    --to=serue@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=containers@lists.osdl.org \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthltc@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®