how to handle devpts

how to handle devpts

[Serge E. Hallyn]

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.

Do we require that it be run in screen?  Then what about the
screen session's terminals themselves?

Anyway, I have this feeling that other have already thought
through this, so here is the simple program for discussion:

#include <stdio.h>
#include <curses.h>
#include <string.h>

int main(int argc, char *argv[])
{
#define MAXLEN 20
	char input[MAXLEN+1];
	int i = 0;

	initscr();
	cbreak();
	//noecho();
	nonl();
	intrflush(stdscr, FALSE);
	keypad(stdscr, TRUE);

	addstr("Enter some text: ");
	memset(input, 0, MAXLEN+1);
	while (1) {
		input[i] = getch();
		if (input[i] == KEY_ENTER || input[i]=='\r')
			break;
		i++;
		if (i == MAXLEN)
			break;
	}
	endwin();
	printf("I read the text: %s\n", input);
	return 0;
}

-serge

Re: how to handle devpts

[Louis Rilling]

[-- Attachment #1.1: Type: text/plain, Size: 2620 bytes --]

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

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.

Hope this makes the discussion progress...

Louis

> 
> Do we require that it be run in screen?  Then what about the
> screen session's terminals themselves?
> 
> Anyway, I have this feeling that other have already thought
> through this, so here is the simple program for discussion:
> 
> #include <stdio.h>
> #include <curses.h>
> #include <string.h>
> 
> int main(int argc, char *argv[])
> {
> #define MAXLEN 20
> 	char input[MAXLEN+1];
> 	int i = 0;
> 
> 	initscr();
> 	cbreak();
> 	//noecho();
> 	nonl();
> 	intrflush(stdscr, FALSE);
> 	keypad(stdscr, TRUE);
> 
> 	addstr("Enter some text: ");
> 	memset(input, 0, MAXLEN+1);
> 	while (1) {
> 		input[i] = getch();
> 		if (input[i] == KEY_ENTER || input[i]=='\r')
> 			break;
> 		i++;
> 		if (i == MAXLEN)
> 			break;
> 	}
> 	endwin();
> 	printf("I read the text: %s\n", input);
> 	return 0;
> }
> 
> -serge
> _______________________________________________
> Containers mailing list
> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linux-foundation.org/mailman/listinfo/containers

-- 
Dr Louis Rilling			Kerlabs
Skype: louis.rilling			Batiment Germanium
Phone: (+33|0) 6 80 89 08 23		80 avenue des Buttes de Coesmes
http://www.kerlabs.com/			35700 Rennes

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Re: how to handle devpts

[Serge E. Hallyn]

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