Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl@xxxxxxxxxxx):
>> 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.
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
