On 09/02/09 21:14 +0100, Cedric Le Goater wrote: [...] > I think that the current way of doing things is work in progress and needs > to be reviewed. The way checkpoint/restart is triggered has always been > controversial among the stakeholders. > > We've been maintaining a C/R solution on ppc32, ppc64, x86, x86_64, ia64, > s390, s390x since 2002 working on the above principles you are describing. > UNICOS and later IRIX used similar principles, following the POSIX draft > on checkpoint/restart. > > For the signal, we have 'hijacked' SIGSTOP but new signals SIGCKPT and > SIGRESTART would definitely be a nicer solution for a mainline solution. In Kerrighed we implemented a variant of signal handler, which is more transparent to userspace. Instead of using userspace signals (for instance SIGRTMIN), we send a signal with si_code = SI_KERRIGHED. When dequeuing such a signal, get_signal_to_deliver() calls the appropriate kernel callback (eg. task_checkpoint()), and then continues as if the signal were ignored. This solution has two nice properties: - no userspace signal is overloaded, so that applications can use whatever signals they want; - every task will eventually handle the signal with the right callback, whether they use the VDSO page or not. Of course there is the matching drawback: userspace cannot use the checkpoint signal to perform application-dependent control. However, this kind of thing could equally be done from the checkpoint callback setting up an application-defined signal handler. Louis -- 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:
signature.asc
Description: Digital signature
_______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
