[Devel] Re: [RFC][PATCH 3/3] c/r: [pty 2/2] support for pseudo terminals

Serge E. Hallyn serue at us.ibm.com
Wed Sep 2 16:05:49 PDT 2009


Quoting Oren Laadan (orenl at librato.com):
> 
> Thanks for the patches (the first was already in). I'll leave
> out the change to signed type, though.

Yup, "oops".

> Serge E. Hallyn wrote:
> > All right, I'm not sure how to go about this - i want to have a conversation
> > involving patches without making it seem like I want any of the patches
> > pushed yet :)  To get this working on s390, I needed the two attached
> > patches.  Then the testcase under git://git.sr71.net/~hallyn/cr_tests.git
> > under cr_tests/pty/ passes with your code.
> > 
> > I'd still like to get a more invasive approach working where we directly
> > ask the pty code to create the pty with the right index.  I'm playing with
> > it right now, but of course having some trouble figuring out what to do
> > for the master end and how best to construct a filp to pass to
> > the main pty_create function.  I'll take a few more stabs and send out
> > what I have later (or announce defeat).
> > 
> > There is certainly something to be said for the un-invasiveness of
> > your approach (and that it works).
> > 
> > In either case, we will need to figure out how to deal with devpts
> > namespaces.  Perhaps we separately checkpoint a 'devpts_mnt'.  It
> > just stores the mountpoint of the mount.  At restart, we don't
> > recreate those, we just confirm that the mountpoints still exist.
> > Then, each pty entry has a ref to its devpts mount, and we use the
> > mountpoint to construct ${mountpoint}/ptmx and pass that to
> > filp_open() or ptmx_create)( to create the pty entry.
> 
> Yes, I was thinking along these lines. I think it's very much
> related to the whole mount-namespaces issues; I guess it's time
> to address both.

Ooooh, I'm not sure it is :)  In fact my approach to devpts should
artfully avoid having to address generic mounts namespaces :)

Well, if we *were* to address mountsns now, I'd suggest we simply
store meaningful /proc/pid/mountinfo data for each task in the
checkpoint image, and just verify it at restart, returning error
if they're not the same.  That way we can continue to defer
the decision on whether mktree or the kernel will restore mounts.

-serge
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list