how to handle devpts
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
A message that is not in the archive (sent off-list or not yet received): 20091130202223.GA20224-r/[email protected]
Hi Serge,
Quoted 5 lines · 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
ttyopen. What do we want to do about that?
Quoted 7 lines
Just having
user-cr/restart.ctake 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
Quoted 44 lines
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
Signature · 4 lines
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
_______________________________________________
Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers
A message that is not in the archive (sent off-list or not yet received): 20091201093708.GC2430-Hu8+6S1rdjywhHL9vcZdMVaTQe2KTcn/@public.gmane.org
Quoted 16 lines · Louis Rilling
Hi Serge,
Quoted 5 lines · 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
ttyopen. What do we want to do about that?Quoted 7 lines
Just having
user-cr/restart.ctake 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.
Quoted 5 lines
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, andsys_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...
Quoted 4 lines
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...
Quoted 1 line
Hope this makes the discussion progress...
Yup, thanks!
-serge