Re: how to handle devpts

["Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Quoting Louis Rilling (Louis.Rilling-aw0BnHfMbSpBDgjK7y7TUQ@public.gmane.org):
> Hi Serge,
> 
> On 30/11/09 14:22 -0600, Serge E. Hallyn wrote:
> > We currently checkpoint and restart unix98 ptys in the kernel.
> > So what do we want to do about the userspace part?  In particular,
> > if I run the following test program and checkpoint it, it
> > has `tty` open.  What do we want to do about that?
> > 
> > Just having user-cr/restart.c take an option to mount a new
> > instance of devpts isn't enough - we don't get hooked up to
> > restart.c's stdin/out obviously, and restart succeeds but the
> > restarted program exists with -EIO.  At the same time, just
> > doing a cradvise type of thing to plug fds 0,1,2 suffice for
> > this testcase, but not for something more complicated which
> > also has other unix98 ptys open.
> 
> In Kerrighed we are implementing something à-la-cradvise: we allow the
> caller of sys_restart() to give replacement fds for arbitrary files. To achieve
> this, each checkpointed file descriptor (struct file) has a unique key, and
> sys_restart() takes a substitution table in parameter, where an entry is a
> pair (key, fd).

Thanks - that sounds somewhat like what I was leaning toward last
night.  In particular, I was thinking that a user-space tool could
walk over the checkpoint image and replace certain checkpointed
filenames with a string like "\0RESERVED_FD0".  Sys_restart() would
see that filename at restore_file() and plug in the coordinator task's
fd 0.

The thing I don't like about it is that I'm replacing pathnames,
and so I worry that applications playing with mounts namespaces
will be a problem for the program rewriting the checkpoint image.
Not insurmountable, but requiring a lot more work...

> In Kerrighed sys_checkpoint() exports a human-readable table of checkpointed
> file descriptors, with types, fd in each checkpointed task, etc.
> With Oren's patchset, I presume that some userspace tool could extract such a
> table from the checkpoint.

Yeah, I guess such a program for analyzing and rewriting resources
in a checkpoint image would be very useful.  Could perhaps also
be used for network interfaces, internal mounts, uids, in-kernel
keyring...

> Hope this makes the discussion progress...

Yup, thanks!

-serge