OpenVZ Forum - RDF feed
type: channel
items: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/
items: [PATCH 2/2] signal c/r: implement /proc/pid/sig writing
items: Re: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/
items: Re: [PATCH 2/2] signal c/r: implement /proc/pid/sig writing
items: Re: Re: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/

[PATCH 1/2] signal checkpoint: define /proc/pid/sig/
type: item
description: As I mentioned earlier, I don't know what sort of approach we want to take to guide checkpoint and restart. I.e. do we want it to be a mostly userspace-orchestrated affair, or entirely done in the kernel using the freezer or some other mechanism in response to a single syscall or containerfs file write? If we wanted to do a lot of the work in userspace, here is a pair of patches to read and restore signal information. It's entirely unsafe wrt locking, bc i would assume that if we did in fact do c/r from userspace, we would have some way of entirely pulling the task off the runqueue while doing our thing... Anyway, this is purely to start discussion. thanks, -serge >From 30bbe322942e5ed86bad63861dad80595cd04063 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <serue@us.ibm.com> Date: Mon, 30 Apr 2007 16:22:44 -0400 Subject: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/ Define /proc/<pid>/sig/ directory containing files to report on a process' signal info. Files defined: action: list signal action altstack: print sigaltstack location and size blocked: print blocked signal mask pending: print pending signals and siginfo shared_pending: print shared pending signals and siginfo waiters: list tasks wait4()ing on task PID. TESTING: In one terminal run 'forker' as compiled from forker.c below. In another terminal, run 'sh checkforker.sh' also included below which will send more signals to the forker, then check it's pending, blocked, and shared_pending sig/ files. ===================================================================== forker.c ===================================================================== void runchild(void) { printf("child exiting\n"); exit(0); } int main() { sigset_t blockset; sigset_t prevset; int pid; if (sigemptyset(&blockset) == -1) { perror("sigemptyset"); return -1; } if (sigaddset(&blockset, SIGUSR1) == -1) { perror("sigaddset"); return -1; } if (sigaddset(&blockset, SIGUSR2) == -1) { perror("sigaddset"); return -1; } if (sigaddset(&block…
creator: serue
date: 2007-06-08T15:54:37-00:00

[PATCH 2/2] signal c/r: implement /proc/pid/sig writing
type: item
description: >From 0fc34dcb54fe80ea720225825ad1dcb1b847d8ab Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <serue@us.ibm.com> Date: Thu, 17 May 2007 17:28:07 -0400 Subject: [PATCH 2/2] signal c/r: implement /proc/pid/sig writing Allow restore through writes to /proc/pid/sig/*, except for the waiters file. Waits must be restored by the waiter actually running wait. To test writes to the action file I use the included handlertest.c. Start it up in one terminal as ./handlertest 1 It should print "using handler 1" in another terminal pid=`ps -ef | grep handlertest | grep -v grep | awk '{ print $2 '}` cat /proc/$pid/sig/action > action kill -USR1 $pid handlertest should print "handler 1 called" You can repeat this with ./handlertest 2 to make sure it does what you expect with the second signal handler. Restart handlertest with a different signal handler: ./handlertest 2 It prints "using handler 2" Overwrite it's sigactions from another terminal pid=`ps -ef | grep handlertest | grep -v grep | awk '{ print $2 '}` cat action > /proc/$pid/sig/action and send it a USR1 kill -USR1 $pid and it should say "handler 1 called". ===================================================================== handlertest.c ===================================================================== void handler1(int sig) { printf("handler 1 called\n"); } void handler2(int sig) { printf("handler 2 called\n"); } int main(int argc, char *argv[]) { int hnum; __sighandler_t h = handler1; if (argc<2) { printf("usage: %s [1|2]\n", argv[0]); exit(2); } hnum = atoi(argv[1]); if (hnum == 1) { printf("using handler 1\n"); } else { h = handler2; printf("using handler 2\n"); } signal(SIGUSR1, h); sleep(100); } Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> --- fs/proc/base.c | 97 +++++++++++++++++++++- include/linux/signal.h | 2 + kernel/signal.c | 218 +++++++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 313 insertions(+), 4 deletions(-) diff --git a/fs/proc/base.c b/fs/proc/base.c index 8e0dd7a..22817bb 100644…
creator: serue
date: 2007-06-08T15:54:58-00:00

Re: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/
type: item
description: Serge E. Hallyn wrote: > As I mentioned earlier, I don't know what sort of approach we want > to take to guide checkpoint and restart. I.e. do we want it to be > a mostly userspace-orchestrated affair, or entirely done in the > kernel using the freezer or some other mechanism in response to a > single syscall or containerfs file write? > > If we wanted to do a lot of the work in userspace, here is a pair of > patches to read and restore signal information. It's entirely unsafe > wrt locking, bc i would assume that if we did in fact do c/r from > userspace, we would have some way of entirely pulling the task off > the runqueue while doing our thing... > > Anyway, this is purely to start discussion. > > thanks, > -serge > >>From 30bbe322942e5ed86bad63861dad80595cd04063 Mon Sep 17 00:00:00 2001 > From: Serge E. Hallyn <serue@us.ibm.com> > Date: Mon, 30 Apr 2007 16:22:44 -0400 > Subject: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/ > > Define /proc/<pid>/sig/ directory containing files to report > on a process' signal info. > > Files defined: > action: list signal action > altstack: print sigaltstack location and size > blocked: print blocked signal mask > pending: print pending signals and siginfo > shared_pending: print shared pending signals and siginfo > waiters: list tasks wait4()ing on task PID. some of these are already in /proc/<pid>/status and /proc/<pid>/stat should we continue to use /proc ? or switch to some other mechanisms like getnetlink (taskstats) to map kernel structures. [ ... ] > +/* > + * print a sigset_t to a buffer. Return # characters printed, > + * not including the final ending '\0'. > + */ > +static int print_sigset(char *buf, sigset_t *sig) > +{ > + int i; > + > + for (i=0; i<_NSIG; i++) { > + if (sigismember(sig, i)) > + buf[i] = '1'; > + else > + buf[i] = '0'; > + } > + buf[_NSIG] = '\0'; > + > + return _NSIG; > +} you might want to use render_sigset_t() in fs/proc array.C > +static int print_sigset_alloc(char **bufp, sigset_t *sig)…
creator: Cedric Le Goater
date: 2007-06-11T14:43:12-00:00

Re: [PATCH 2/2] signal c/r: implement /proc/pid/sig writing
type: item
description: with all the infos you've gathered in /proc, why don't you just kill the process ? The patch we have to restore pending signals in 2.6.21-mm2-lxc3 does : +static int pid_set_siginfo(mcrk_session_t * s, void *ptarg) +{ + mcrk_pid_setsignal_t arg; + siginfo_t si; + int ret; + + if (!ptarg) { + return -EINVAL; + } + + if (copy_from_user(&arg, ptarg, sizeof(arg))) + return -EFAULT; + if (copy_from_user(&si, U64_2_PTR(arg.siginfo), sizeof(si))) + return -EFAULT; + + if (arg.shared) { + ret = kill_proc_info(si.si_signo, &si, current->pid); + } else { + ret = send_sig_info(si.si_signo, &si, current); + } + return ret; +} C. Serge E. Hallyn wrote: >>From 0fc34dcb54fe80ea720225825ad1dcb1b847d8ab Mon Sep 17 00:00:00 2001 > From: Serge E. Hallyn <serue@us.ibm.com> > Date: Thu, 17 May 2007 17:28:07 -0400 > Subject: [PATCH 2/2] signal c/r: implement /proc/pid/sig writing > > Allow restore through writes to /proc/pid/sig/*, except for > the waiters file. Waits must be restored by the waiter actually > running wait. > > To test writes to the action file I use the included handlertest.c. > Start it up in one terminal as > ./handlertest 1 > It should print "using handler 1" > in another terminal > pid=`ps -ef | grep handlertest | grep -v grep | awk '{ print $2 '}` > cat /proc/$pid/sig/action > action > kill -USR1 $pid > handlertest should print "handler 1 called" > > You can repeat this with > ./handlertest 2 > to make sure it does what you expect with the second signal handler. > > Restart handlertest with a different signal handler: > ./handlertest 2 > It prints "using handler 2" > Overwrite it's sigactions from another terminal > pid=`ps -ef | grep handlertest | grep -v grep | awk '{ print $2 '}` > cat action > /proc/$pid/sig/action > and send it a USR1 > kill -USR1 $pid > and it should say "handler 1 called". > > ===================================================================== > handlertest.c > ===================================================================== > > void h…
creator: Cedric Le Goater
date: 2007-06-11T14:53:16-00:00

Re: [PATCH 2/2] signal c/r: implement /proc/pid/sig writing
type: item
description: Quoting Cedric Le Goater (clg@fr.ibm.com): > with all the infos you've gathered in /proc, why don't you just kill the > process ? > > The patch we have to restore pending signals in 2.6.21-mm2-lxc3 does : > > +static int pid_set_siginfo(mcrk_session_t * s, void *ptarg) > +{ > + mcrk_pid_setsignal_t arg; > + siginfo_t si; > + int ret; > + > + if (!ptarg) { > + return -EINVAL; > + } > + > + if (copy_from_user(&arg, ptarg, sizeof(arg))) > + return -EFAULT; > + if (copy_from_user(&si, U64_2_PTR(arg.siginfo), sizeof(si))) > + return -EFAULT; Hmm, one problem with especially this second copy_from_user() is that you are making the checkpoint image more kernel dependant. Whatever approach we take both high-level and low-level, we do want to avoid having checkpoint images directly reflect in-kernel structures, right? That's one area where the /proc approach has an inherent advantage over using netlink to dump information, it avoids the temptation to just dump and restore straight from the kernel pointer, which would threaten to make restoring a checkpoint from another kernel much more dangerous. > + if (arg.shared) { > + ret = kill_proc_info(si.si_signo, &si, current->pid); > + } else { > + ret = send_sig_info(si.si_signo, &si, current); > + } > + return ret; > +} This part is fine with me, but assumes we take the more kernel-guided approach, right. And that's what I'm trying to get people to discuss :) Do we want a more kernel-guided approach, or do we want to provide pieces of functionality that userspace exploits? Oh, or are you saying this would just replace the biggest chunk of my set_sigpending() function below? thanks, -serge > > C. > > Serge E. Hallyn wrote: > >>From 0fc34dcb54fe80ea720225825ad1dcb1b847d8ab Mon Sep 17 00:00:00 2001 > > From: Serge E. Hallyn <serue@us.ibm.com> > > Date: Thu, 17 May 2007 17:28:07 -0400 > > Subject: [PATCH 2/2] signal c/r: implement /proc/pid/sig writing > > > > Allow restore through writes to /proc/pid/sig/*, except for > > the waiters…
creator: serue
date: 2007-06-11T16:47:47-00:00

Re: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/
type: item
description: Quoting Cedric Le Goater (clg@fr.ibm.com): > Serge E. Hallyn wrote: > > As I mentioned earlier, I don't know what sort of approach we want > > to take to guide checkpoint and restart. I.e. do we want it to be > > a mostly userspace-orchestrated affair, or entirely done in the > > kernel using the freezer or some other mechanism in response to a > > single syscall or containerfs file write? > > > > If we wanted to do a lot of the work in userspace, here is a pair of > > patches to read and restore signal information. It's entirely unsafe > > wrt locking, bc i would assume that if we did in fact do c/r from > > userspace, we would have some way of entirely pulling the task off > > the runqueue while doing our thing... > > > > Anyway, this is purely to start discussion. > > > > thanks, > > -serge > > > >>From 30bbe322942e5ed86bad63861dad80595cd04063 Mon Sep 17 00:00:00 2001 > > From: Serge E. Hallyn <serue@us.ibm.com> > > Date: Mon, 30 Apr 2007 16:22:44 -0400 > > Subject: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/ > > > > Define /proc/<pid>/sig/ directory containing files to report > > on a process' signal info. > > > > Files defined: > > action: list signal action > > altstack: print sigaltstack location and size > > blocked: print blocked signal mask > > pending: print pending signals and siginfo > > shared_pending: print shared pending signals and siginfo > > waiters: list tasks wait4()ing on task PID. > > some of these are already in /proc/<pid>/status and /proc/<pid>/stat Good point. However they can't be set through that file. So is it worth making the files write-only, to avoid duplication, or do we prefer to not make the checkpoint and restart use different files? > should we continue to use /proc ? or switch to some other mechanisms > like getnetlink (taskstats) to map kernel structures. We want to avoid 'map'ping kernel structures, though, right? We can dump the data in a more generic fashion through netlink, dunno what we prefer. But this is very d…
creator: serue
date: 2007-06-11T17:05:37-00:00

Re: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/
type: item
description: On 11.06.2007 19:05, Serge E. Hallyn wrote: > Quoting Cedric Le Goater (clg@fr.ibm.com): > >> should we continue to use /proc ? or switch to some other mechanisms >> like getnetlink (taskstats) to map kernel structures. > > We want to avoid 'map'ping kernel structures, though, right? We can > dump the data in a more generic fashion through netlink, dunno what we > prefer. But this is very definately process information :), so /proc > does seem appropriate. While I agree that /proc seems appropriate, I see a few benefits of dumping the data through netlink: * Speed. IIRC there were benchmarks showing an advantage of netlink over /proc when communicating with userspace. Sorry, no idea where I read that. * Versioning. While we strive to have the perfect interface on the first try, changes might be necessary. I see no way to handle multiple versions of an interface in /proc without big headaches. * Conformity. With /proc, people often see a file, take a look at it and try to infer the structure of the file from what they see. This has led to multiple problems in the past when the content of some files in /proc changed slightly and tools broke. With netlink, implementers have to look at the spec to achieve anything useful. Regards, Carl-Daniel _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Carl-Daniel Hailfinge
date: 2007-06-12T15:29:38-00:00

Re: Re: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/
type: item
description: Carl-Daniel Hailfinger wrote: > On 11.06.2007 19:05, Serge E. Hallyn wrote: >> Quoting Cedric Le Goater (clg@fr.ibm.com): >> >>> should we continue to use /proc ? or switch to some other mechanisms >>> like getnetlink (taskstats) to map kernel structures. >> We want to avoid 'map'ping kernel structures, though, right? We can >> dump the data in a more generic fashion through netlink, dunno what we >> prefer. But this is very definately process information :), so /proc >> does seem appropriate. > > While I agree that /proc seems appropriate, I see a few benefits of > dumping the data through netlink: > * Speed. IIRC there were benchmarks showing an advantage of netlink > over /proc when communicating with userspace. Sorry, no idea where > I read that. > * Versioning. While we strive to have the perfect interface on the > first try, changes might be necessary. I see no way to handle > multiple versions of an interface in /proc without big headaches. > * Conformity. With /proc, people often see a file, take a look at > it and try to infer the structure of the file from what they see. > This has led to multiple problems in the past when the content of > some files in /proc changed slightly and tools broke. With > netlink, implementers have to look at the spec to achieve anything > useful. Right. And community seems to encourage to use the netlink and to stop implementing new entry in /proc. http://kerneltrap.org/node/6637 _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Daniel Lezcano
date: 2007-06-12T16:02:40-00:00

Re: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/
type: item
description: Quoting Carl-Daniel Hailfinger (c-d.hailfinger.devel.2006@gmx.net): > On 11.06.2007 19:05, Serge E. Hallyn wrote: > > Quoting Cedric Le Goater (clg@fr.ibm.com): > > > >> should we continue to use /proc ? or switch to some other mechanisms > >> like getnetlink (taskstats) to map kernel structures. > > > > We want to avoid 'map'ping kernel structures, though, right? We can > > dump the data in a more generic fashion through netlink, dunno what we > > prefer. But this is very definately process information :), so /proc > > does seem appropriate. > > While I agree that /proc seems appropriate, I see a few benefits of > dumping the data through netlink: Good points, thanks. > * Speed. IIRC there were benchmarks showing an advantage of netlink > over /proc when communicating with userspace. Sorry, no idea where > I read that. I don't think we're dumping large amounts of data (the largest amounts, process memory, we're looking at doing just by forcing dump to swap), so I'm not sure how much it matters. Still, > * Versioning. While we strive to have the perfect interface on the > first try, changes might be necessary. I see no way to handle > multiple versions of an interface in /proc without big headaches. Good point, this kind of offsets my major point against netlink, that we'd likely inherently end up versioning the interface by being tempted to dump kernel structures verbatim. I doubt anyone would claim that we'll never need to update the /proc interface, so that may make using /proc a nonstarter. > * Conformity. With /proc, people often see a file, take a look at > it and try to infer the structure of the file from what they see. > This has led to multiple problems in the past when the content of > some files in /proc changed slightly and tools broke. With > netlink, implementers have to look at the spec to achieve anything > useful. Ok, so presumably we'd want some 'start a checkpoint' or 'start a restore' command (through syscall or whatever) to create the netlink s…
creator: serue
date: 2007-06-12T16:12:56-00:00

Re: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/
type: item
description: [ ... ] >>> +static int print_sigpending_alloc(char **bufp, struct sigpending *pending) >>> +{ >>> + int alloced=0; >>> + char *buf, *p; >>> + struct sigqueue *q; >>> + struct siginfo *info; >>> + >>> + alloced = PAGE_SIZE; >>> + p = buf = kmalloc(alloced, GFP_KERNEL); >>> + if (!buf) >>> + return -ENOMEM; >>> + >>> + p += print_sigset(buf, &pending->signal); >>> + p += sprintf(p, "\n"); >>> + >>> + list_for_each_entry(q, &pending->list, list) { >>> + info = &q->info; >>> + if (p-buf+215 > alloced) { >>> + int len=p-buf; >>> + char *buf2; >>> + alloced += PAGE_SIZE; >>> + buf2 = kmalloc(alloced, GFP_KERNEL); >>> + if (!buf2) { >>> + kfree(buf); >>> + return -ENOMEM; >>> + } >>> + memcpy(buf2, buf, alloced - PAGE_SIZE); >>> + kfree(buf); >>> + buf = buf2; >>> + p = buf+len; >>> + } >>> + >>> + p += sprintf(p, "sig %d: user %d flags %d", >>> + info->si_signo, (int)q->user->uid, q->flags); >>> + p += sprintf(p, " errno %d code %d\n", >>> + info->si_errno, info->si_code); >>> + >>> + switch(info->si_signo) { >>> + case SIGKILL: >>> + p += sprintf(p, " spid %d suid %d\n", >>> + info->_sifields._kill._pid, >>> + info->_sifields._kill._uid); >>> + break; >>> + /* XXX skipping posix1b timers and signals for now */ >>> + case SIGCHLD: >>> + p += sprintf(p, " pid %d uid %d status %d utime %lu stime %lu\n", >>> + info->_sifields._sigchld._pid, >>> + info->_sifields._sigchld._uid, >>> + info->_sifields._sigchld._status, >>> + info->_sifields._sigchld._utime, >>> + info->_sifields._sigchld._stime); >>> + break; >>> + case SIGILL: >>> + case SIGFPE: >>> + case SIGSEGV: >>> + case SIGBUS: >>> +#ifdef __ARCH_SI_TRAPNO >>> + p += sprintf(p, " addr %lu trapno %d\n", >>> + (unsigned long)info->_sifields._sigfault._addr, >>> + info->_sifields._sigfault._trapno); >>> +#else >>> + p += sprintf(p, " addr %lu\n", >>> + (unsigned long)info->_sifields._sigfault._addr); >>> +#endif >>> + break; >>> + case SIGPOLL: >>> + p += sprintf(p, " band %ld fd %d\n", >>> + (long)info->_sifields._sigpoll…
creator: Cedric Le Goater
date: 2007-06-12T16:30:46-00:00

Re: [PATCH 2/2] signal c/r: implement /proc/pid/sig writing
type: item
description: Serge E. Hallyn wrote: > Quoting Cedric Le Goater (clg@fr.ibm.com): >> with all the infos you've gathered in /proc, why don't you just kill the >> process ? >> >> The patch we have to restore pending signals in 2.6.21-mm2-lxc3 does : >> >> +static int pid_set_siginfo(mcrk_session_t * s, void *ptarg) >> +{ >> + mcrk_pid_setsignal_t arg; >> + siginfo_t si; >> + int ret; >> + >> + if (!ptarg) { >> + return -EINVAL; >> + } >> + >> + if (copy_from_user(&arg, ptarg, sizeof(arg))) >> + return -EFAULT; >> + if (copy_from_user(&si, U64_2_PTR(arg.siginfo), sizeof(si))) >> + return -EFAULT; > > Hmm, one problem with especially this second copy_from_user() is that > you are making the checkpoint image more kernel dependant. right. we need an opaque structure to hold the siginfo data. > Whatever approach we take both high-level and low-level, we do want to > avoid having checkpoint images directly reflect in-kernel structures, > right? yes. > That's one area where the /proc approach has an inherent advantage over > using netlink to dump information, it avoids the temptation to just dump > and restore straight from the kernel pointer, which would threaten to > make restoring a checkpoint from another kernel much more dangerous. I agree. You have to be self disciplined and define nice structures for all the data you want to exchange between kernel and user. >> + if (arg.shared) { >> + ret = kill_proc_info(si.si_signo, &si, current->pid); >> + } else { >> + ret = send_sig_info(si.si_signo, &si, current); >> + } >> + return ret; >> +} > > This part is fine with me, but assumes we take the more kernel-guided > approach, right. > > And that's what I'm trying to get people to discuss :) Do we want a > more kernel-guided approach, or do we want to provide pieces of > functionality that userspace exploits? > > Oh, or are you saying this would just replace the biggest chunk of my > set_sigpending() function below? I think so :) cheers, C. _______________________________________________ Co…
creator: Cedric Le Goater
date: 2007-06-12T16:44:44-00:00

Re: Re: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/
type: item
description: Quoting Daniel Lezcano (dlezcano@fr.ibm.com): > Carl-Daniel Hailfinger wrote: > >On 11.06.2007 19:05, Serge E. Hallyn wrote: > >>Quoting Cedric Le Goater (clg@fr.ibm.com): > >> > >>>should we continue to use /proc ? or switch to some other mechanisms > >>>like getnetlink (taskstats) to map kernel structures. > >>We want to avoid 'map'ping kernel structures, though, right? We can > >>dump the data in a more generic fashion through netlink, dunno what we > >>prefer. But this is very definately process information :), so /proc > >>does seem appropriate. > > > >While I agree that /proc seems appropriate, I see a few benefits of > >dumping the data through netlink: > >* Speed. IIRC there were benchmarks showing an advantage of netlink > > over /proc when communicating with userspace. Sorry, no idea where > > I read that. > >* Versioning. While we strive to have the perfect interface on the > > first try, changes might be necessary. I see no way to handle > > multiple versions of an interface in /proc without big headaches. > >* Conformity. With /proc, people often see a file, take a look at > > it and try to infer the structure of the file from what they see. > > This has led to multiple problems in the past when the content of > > some files in /proc changed slightly and tools broke. With > > netlink, implementers have to look at the spec to achieve anything > > useful. > > Right. And community seems to encourage to use the netlink and to stop > implementing new entry in /proc. > > http://kerneltrap.org/node/6637 That's not quite what that thread is saying :) For just this information, I would prefer /proc over netlink. But since we'll be dumping a whole bunch more data, I agree netlink may be the way to go. thanks, -serge _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: serue
date: 2007-06-12T16:55:55-00:00

Re: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/
type: item
description: Serge E. Hallyn wrote: > Quoting Carl-Daniel Hailfinger (c-d.hailfinger.devel.2006@gmx.net): >> On 11.06.2007 19:05, Serge E. Hallyn wrote: >>> Quoting Cedric Le Goater (clg@fr.ibm.com): >>> >>>> should we continue to use /proc ? or switch to some other mechanisms >>>> like getnetlink (taskstats) to map kernel structures. >>> We want to avoid 'map'ping kernel structures, though, right? We can >>> dump the data in a more generic fashion through netlink, dunno what we >>> prefer. But this is very definately process information :), so /proc >>> does seem appropriate. >> While I agree that /proc seems appropriate, I see a few benefits of >> dumping the data through netlink: > > Good points, thanks. > >> * Speed. IIRC there were benchmarks showing an advantage of netlink >> over /proc when communicating with userspace. Sorry, no idea where >> I read that. > > I don't think we're dumping large amounts of data (the largest amounts, > process memory, we're looking at doing just by forcing dump to swap), so > I'm not sure how much it matters. > > Still, > >> * Versioning. While we strive to have the perfect interface on the >> first try, changes might be necessary. I see no way to handle >> multiple versions of an interface in /proc without big headaches. > > Good point, this kind of offsets my major point against netlink, that > we'd likely inherently end up versioning the interface by being tempted > to dump kernel structures verbatim. I doubt anyone would claim that > we'll never need to update the /proc interface, so that may make using > /proc a nonstarter. > >> * Conformity. With /proc, people often see a file, take a look at >> it and try to infer the structure of the file from what they see. >> This has led to multiple problems in the past when the content of >> some files in /proc changed slightly and tools broke. With >> netlink, implementers have to look at the spec to achieve anything >> useful. > > Ok, so presumably we'd want some 'start a checkpoint' or 'start …
creator: Daniel Lezcano
date: 2007-06-14T14:36:30-00:00

Re: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/
type: item
description: Serge E. Hallyn wrote: > Quoting Carl-Daniel Hailfinger (c-d.hailfinger.devel.2006@gmx.net): >> On 11.06.2007 19:05, Serge E. Hallyn wrote: >>> Quoting Cedric Le Goater (clg@fr.ibm.com): >>> >>>> should we continue to use /proc ? or switch to some other mechanisms >>>> like getnetlink (taskstats) to map kernel structures. >>> We want to avoid 'map'ping kernel structures, though, right? We can >>> dump the data in a more generic fashion through netlink, dunno what we >>> prefer. But this is very definately process information :), so /proc >>> does seem appropriate. >> While I agree that /proc seems appropriate, I see a few benefits of >> dumping the data through netlink: > > Good points, thanks. > >> * Speed. IIRC there were benchmarks showing an advantage of netlink >> over /proc when communicating with userspace. Sorry, no idea where >> I read that. > > I don't think we're dumping large amounts of data (the largest amounts, > process memory, we're looking at doing just by forcing dump to swap), so > I'm not sure how much it matters. > > Still, > >> * Versioning. While we strive to have the perfect interface on the >> first try, changes might be necessary. I see no way to handle >> multiple versions of an interface in /proc without big headaches. > > Good point, this kind of offsets my major point against netlink, that > we'd likely inherently end up versioning the interface by being tempted > to dump kernel structures verbatim. I doubt anyone would claim that > we'll never need to update the /proc interface, so that may make using > /proc a nonstarter. > >> * Conformity. With /proc, people often see a file, take a look at >> it and try to infer the structure of the file from what they see. >> This has led to multiple problems in the past when the content of >> some files in /proc changed slightly and tools broke. With >> netlink, implementers have to look at the spec to achieve anything >> useful. > > Ok, so presumably we'd want some 'start a checkpoint' or 'start …
creator: Daniel Lezcano
date: 2007-06-14T14:38:07-00:00

Re: [PATCH 1/2] signal checkpoint: define /proc/pid/sig/
type: item
description: Quoting Daniel Lezcano (dlezcano@fr.ibm.com): > Serge E. Hallyn wrote: > >Quoting Carl-Daniel Hailfinger (c-d.hailfinger.devel.2006@gmx.net): > >>On 11.06.2007 19:05, Serge E. Hallyn wrote: > >>>Quoting Cedric Le Goater (clg@fr.ibm.com): > >>> > >>>>should we continue to use /proc ? or switch to some other mechanisms > >>>>like getnetlink (taskstats) to map kernel structures. > >>>We want to avoid 'map'ping kernel structures, though, right? We can > >>>dump the data in a more generic fashion through netlink, dunno what we > >>>prefer. But this is very definately process information :), so /proc > >>>does seem appropriate. > >>While I agree that /proc seems appropriate, I see a few benefits of > >>dumping the data through netlink: > > > >Good points, thanks. > > > >>* Speed. IIRC there were benchmarks showing an advantage of netlink > >> over /proc when communicating with userspace. Sorry, no idea where > >> I read that. > > > >I don't think we're dumping large amounts of data (the largest amounts, > >process memory, we're looking at doing just by forcing dump to swap), so > >I'm not sure how much it matters. > > > >Still, > > > >>* Versioning. While we strive to have the perfect interface on the > >> first try, changes might be necessary. I see no way to handle > >> multiple versions of an interface in /proc without big headaches. > > > >Good point, this kind of offsets my major point against netlink, that > >we'd likely inherently end up versioning the interface by being tempted > >to dump kernel structures verbatim. I doubt anyone would claim that > >we'll never need to update the /proc interface, so that may make using > >/proc a nonstarter. > > > >>* Conformity. With /proc, people often see a file, take a look at > >> it and try to infer the structure of the file from what they see. > >> This has led to multiple problems in the past when the content of > >> some files in /proc changed slightly and tools broke. With > >> netlink, implementers have to look at the …
creator: serue
date: 2007-07-02T21:40:40-00:00