[CRIU] Re: [PATCH 2/4] tty: Add checkpoint/restore for unix
terminals v3
Cyrill Gorcunov
gorcunov at openvz.org
Sat Sep 8 14:03:36 EDT 2012
On Sat, Sep 08, 2012 at 09:34:02PM +0400, Pavel Emelyanov wrote:
> On 09/07/2012 09:19 PM, Cyrill Gorcunov wrote:
> > On Fri, Sep 07, 2012 at 06:49:18PM +0400, Pavel Emelyanov wrote:
> >> On 09/07/2012 06:45 PM, Cyrill Gorcunov wrote:
> >>> On Fri, Sep 07, 2012 at 06:39:33PM +0400, Pavel Emelyanov wrote:
> >>>>
> >>>> You assign the n_c_cc = TERMIOS_NCC, thus you should check in on restore.
> >>>
> >>> Ah, that. I'll do a fix on top. Thanks!
> >>>
> >>>> OK, this patch looks sane. Where's the rest with control terminals?
> >>>
> >>> I'm cooking control terminals now (this requires more efforts than I
> >>> expected because I redesigned it, now control terminals should have
> >>> more transparent scheme of restore). Once it's done i'll send them
> >>> out. If you wish you can merge these patches since our test cases
> >>> do work with them just fine.
> >>
> >> No, I will wait for the control ptys. I don't understand the .proto file
> >> layout you chose, need to see the whole picture.
> >
> > OK, does the patch attached shed some light? Note I remember your complain
> > about walking over pstree entries looking up for the task we need, but there
> > not much we can do -- both tasks and ttys are dumped in different time and
> > restored separately so I think we rather need some hash for pstree to find
> > required entry fast.
> >
> > Cyrill
>
> I still don't see the need in _additional_ tty entry for every tty which has
> sid and pgid set. Why not simply put sid and pgid right on the entry of the
> tty which has them set?
As far as I know there might be only one controlling terminal per session, so
we will have only one redundant record here. Also we need to do ioctl on
/dev/pts/N from the task which sid matches to the value controlling terminal has.
Thus we do a trick -- create some fake service fd (fdinfo) and bound data
(such as pty index) to it. This allows our file engine to "open" this fd,
and our "open" procedure will do ioctl on proper /dev/pts/N file. Sounds
reasonable, or still unclear?
Cyrill
More information about the CRIU
mailing list