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

[Oren Laadan <orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>]

Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org):
>> 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 :)

lol .. I suppose I misinterpreted then. Perhaps you can take a
stab at it ?

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

What is "meaningful" data, and how would you "verify" it ?

At restart the mount data may be substantially (and intentionally)
different. For instance, what used to be a local mount at checkpoint
may be an NFS mount at restart....

Oren.