From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oren Laadan Subject: Re: [Devel] [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts Date: Wed, 06 Feb 2008 14:47:07 -0500 Message-ID: <47AA0EBB.3020806@cs.columbia.edu> References: <20080206050428.GA19461@us.ibm.com> <20080206051055.GC19764@us.ibm.com> <47A9D8D4.6030404@openvz.org> <20080206161608.GA16278@sergelap.austin.ibm.com> <47A9DF31.2040302@openvz.org> <20080206164328.GA16726@sergelap.austin.ibm.com> <47AA0995.9020003@cs.columbia.edu> <20080206193724.GB19349@sergelap.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20080206193724.GB19349-6s5zFf/epYLPQpwDFJZrxKsjOiXwFzmk@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Serge E. Hallyn" Cc: Containers , Cedric Le Goater , Pavel Emelyanov List-Id: containers.vger.kernel.org Serge E. Hallyn wrote: > Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org): >> >> Serge E. Hallyn wrote: >>> Quoting Pavel Emelyanov (xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org): >>>> Serge E. Hallyn wrote: >>>>> Quoting Pavel Emelyanov (xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org): >>>>>> sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org wrote: >>>>>>> From: Sukadev Bhattiprolu >>>>>>> Subject: [RFC][PATCH 3/4]: Enable multiple mounts of /dev/pts >> [SNIP] >> >>>>>> That stuff becomes very very similar to that in proc :) >>>>>> Makes sense to consolidate. Maybe... >>>>> Yeah, and the mqns that Cedric sent too. I think Cedric said he'd >>>>> started an a patch implementing a helper. Cedric? >>>> Mmm. I wanted to send one small objection to Cedric's patches with mqns, >>>> but the thread was abandoned by the time I decided to do-it-right-now. >>>> >>>> So I can put it here: forcing the CLONE_NEWNS is not very good, since >>>> this makes impossible to push a bind mount inside a new namespace, which >>>> may operate in some chroot environment. But this ability is heavily >>> Which direction do you want to go? I'm wondering whether mounts >>> propagation can address it. >>> Though really, I think you're right - we shouldn't break the kernel >>> doing CLONE_NEWMQ or CLONE_NEWPTS without CLONE_NEWNS, so we shouldn't >>> force the combination. >>>> exploited in OpenVZ, so if we can somehow avoid forcing the NEWNS flag >>>> that would be very very good :) See my next comment about this issue. >>>> >>>>> Pavel, not long ago you said you were starting to look at tty and pty >>>>> stuff - did you have any different ideas on devpts virtualization, or >>>>> are you ok with this minus your comments thus far? >>>> I have a similar idea of how to implement this, but I didn't thought >>>> about the details. As far as this issue is concerned, I see no reasons >>>> why we need a kern_mount-ed devtpsfs instance. If we don't make such, >>>> we may safely hold the ptsns from the superblock and be happy. The >>>> same seems applicable to the mqns, no? >>> But the current->nsproxy->devpts->mnt is used in several functions in >>> patch 3. >>>> The reason I have the kern_mount-ed instance of proc for pid namespaces >>>> is that I need a vfsmount to flush task entries from, but allowing >>>> it to be NULL (i.e. no kern_mount, but optional user mounts) means >>>> handing all the possible races, which is too heavy. But do we actually >>>> need the vfsmount for devpts and mqns if no user-space mounts exist? >>>> >>>> Besides, I planned to include legacy ptys virtualization and console >>>> virtualizatin in this namespace, but it seems, that it is not present >>>> in this particular one. >>> I had been thinking the consoles would have their own ns, since there's >>> really nothing linking them, but there really is no good reason why >>> userspace should ever want them separate. So I'm fine with combining >>> them. >> If you want to run something like an X server inside each container >> (eg each container holds a desktop session of a different user), then >> you need a separate virtual-console namespace for each container. > > Ok, but whether the consoles and devpts are unshared with the same > cloneflag or not isn't an issue, right? true. (I misread your comment.) ( modulo that we are additional-clone-flags-challenged ...) > >> (yes, X per-se needs to provide remote display as opposed to use >> local hardware; see http://www.ncl.cs.columbia.edu/research/thinc/) > > -serge