From: "H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
To: sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org
Cc: Containers <containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Subject: Re: [RFC][PATCH 0/7] Clone PTS namespace
Date: Wed, 09 Apr 2008 11:01:16 -0700 [thread overview]
Message-ID: <47FD046C.6070804@zytor.com> (raw)
In-Reply-To: <20080409162353.GA14044-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org wrote:
> We want to provide isolation between containers, meaning PTYs in container
> C1 should not be accessible to processes in C2 (unless C2 is an ancestor).
Yes, I certainly can understand the desire for isolation. That wasn't
what my question was about.
> The other reason for this in the longer term is for checkpoint/restart.
> When restarting an application we want to make sure that the PTY indices
> it was using is available and isolated.
OK, this would be the motivation for index isolation.
> A complete device-namespace could solve this, but IIUC, is being planned
> in the longer term. We are hoping this would provide the isolation in the
> near-term without being too intrusive or impeding the implementation of
> the device namespace.
I'm just worried about the accumulation of what feels like ad hoc
namespaces, causing a very large combination matrix, a lot of which
don't make sense.
-hpa
WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: sukadev@us.ibm.com
Cc: linux-kernel@vger.kernel.org,
Containers <containers@lists.osdl.org>,
Pavel Emelyanov <xemul@openvz.org>,
serue@us.ibm.com, clg@fr.ibm.com
Subject: Re: [RFC][PATCH 0/7] Clone PTS namespace
Date: Wed, 09 Apr 2008 11:01:16 -0700 [thread overview]
Message-ID: <47FD046C.6070804@zytor.com> (raw)
In-Reply-To: <20080409162353.GA14044@us.ibm.com>
sukadev@us.ibm.com wrote:
> We want to provide isolation between containers, meaning PTYs in container
> C1 should not be accessible to processes in C2 (unless C2 is an ancestor).
Yes, I certainly can understand the desire for isolation. That wasn't
what my question was about.
> The other reason for this in the longer term is for checkpoint/restart.
> When restarting an application we want to make sure that the PTY indices
> it was using is available and isolated.
OK, this would be the motivation for index isolation.
> A complete device-namespace could solve this, but IIUC, is being planned
> in the longer term. We are hoping this would provide the isolation in the
> near-term without being too intrusive or impeding the implementation of
> the device namespace.
I'm just worried about the accumulation of what feels like ad hoc
namespaces, causing a very large combination matrix, a lot of which
don't make sense.
-hpa
next prev parent reply other threads:[~2008-04-09 18:01 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-08 21:53 [RFC][PATCH 0/7] Clone PTS namespace sukadev
2008-04-08 21:58 ` [RFC][PATCH 1/7]: Propagate error code from devpts_pty_new sukadev
2008-04-08 21:58 ` [RFC][PATCH 2/7]: Factor out PTY index allocation sukadev
2008-04-08 21:59 ` [RFC][PATCH 3/7]: Enable multiple mounts of /dev/pts sukadev
2008-04-08 21:59 ` [RFC][PATCH 4/7]: Allow mknod of ptmx and tty in devpts sukadev
2008-04-08 22:00 ` [RFC][PATCH 5/7]: Implement get_pts_ns() and put_pts_ns() sukadev
2008-04-08 22:00 ` [RFC][PATCH 6/7]: Determine pts_ns from a pty's inode sukadev
2008-04-08 22:00 ` [RFC][PATCH 7/7]: Enable cloning PTY namespaces sukadev
[not found] ` <20080408215333.GA8799-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-04-09 0:53 ` [RFC][PATCH 0/7] Clone PTS namespace H. Peter Anvin
2008-04-09 0:53 ` H. Peter Anvin
[not found] ` <47FC138B.4070408-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
2008-04-09 16:23 ` sukadev-r/Jw6+rmf7HQT0dZR+AlfA
2008-04-09 16:23 ` sukadev
[not found] ` <20080409162353.GA14044-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-04-09 18:01 ` H. Peter Anvin [this message]
2008-04-09 18:01 ` H. Peter Anvin
2008-04-09 19:16 ` serge
2008-04-09 22:38 ` H. Peter Anvin
2008-04-09 22:15 ` Eric W. Biederman
2008-04-09 22:15 ` Eric W. Biederman
2008-04-10 1:59 ` Serge E. Hallyn
2008-04-10 7:36 ` Eric W. Biederman
2008-04-10 16:44 ` Serge E. Hallyn
2008-04-10 20:58 ` sukadev
2008-04-22 14:25 ` Serge E. Hallyn
[not found] ` <20080422142539.GA12623-6s5zFf/epYLPQpwDFJZrxKsjOiXwFzmk@public.gmane.org>
2008-04-22 18:53 ` Eric W. Biederman
2008-04-22 18:53 ` Eric W. Biederman
2008-04-23 14:36 ` Serge E. Hallyn
2008-04-23 17:57 ` Serge E. Hallyn
2008-04-23 18:49 ` Eric W. Biederman
2008-04-25 19:21 ` Serge E. Hallyn
2008-04-25 19:47 ` Eric W. Biederman
2008-04-26 13:02 ` Serge E. Hallyn
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=47FD046C.6070804@zytor.com \
--to=hpa-ymnouzjc4hwavxtiumwx3w@public.gmane.org \
--cc=clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
--cc=xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.