[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gomd-devel] <CHPOX AUTHORS> Chpox support in gomd

From: Gian Paolo Ghilardi
Subject: [gomd-devel] <CHPOX AUTHORS> Chpox support in gomd
Date: Fri, 31 Oct 2003 19:27:19 +0100

Here is the answer from chpox's authors.

Relaly interesting. ;)


----- Original Message -----
From: "csaa" <address@hidden>
To: "Gian Paolo Ghilardi" <address@hidden>
Cc: <address@hidden>
Sent: Friday, October 31, 2003 6:15 PM
Subject: Re: Chpox support in gomd

> Hello Gian,
> Thank you for your interest to chpox project and for wish
> to integrate support of chpox into gomd. Good userlevel
> support should extend the capabilities of
> checkpoint/restart and usage convenience. I like your
> development plan and wish to make some suggestions.
> I think that the first feature should be implemented is support of
> operations (registering, checkpointing, rotation of checkpoint files). So
> Phase#1 should be the most rational. Probably one thread is enough
> because registering and sending checkpoint signals are rather fast.
> I also think that it is necessary to provide some kind of checkpoint files
> versions for the posibility that user can choose not the last checkpoint
> some earlier. This also should provide aditional backup copies in the
> case your last checkpoint becomes broken. At first we thought to
> integrate it with chpox, but then decided that this is not the kernel
> business and it is better to implement it in userlevel.
> Another thing I can suggest
> is automatic restart of checkpointed process after system
> reboot. Many users should like this feature.
> There are also may
> be some problems. The first is concerned with registering. If you need to
register a
> single process - it is quite easy. Old chpox versions supported only
single processes.
> Now chpox was extended
> to support of communicating processes. So it is necessary to specify
> several process that need to be checkpointed togather. Now this can
> be done by registering the parent pid and setting the flag to
> checkpoint chlidren. It is enough for communication via pipes (in
> most cases). But now we are working on support of sockets on single
> machine. It should be necessary to checkpoint togather  processes that
> has no common parent. So registering mechanism may be changed.
> Another problem, that checkpointing/restart may be a large security hole
> and it is necessary to remember about it.
> If we have new ideas we shall inform you. If you have any questions
> fell free to contact me.
> Regards
> Olexander Sudakov
> Wednesday, October 29, 2003, 8:14:05 PM, you wrote:
> GPG> Hi.
> GPG> I'm one of the developers of the "general openMosix daemon" (gomd).
> GPG> The goal of this project is to support all openMosix tools so your
> GPG> chpox program is in our TODO list and we'd like to start a fruitful
> GPG> cooperation with you all to implement this support in the right way
(you are
> GPG> the authors so your suggestions/hints/criticisms are really important
> GPG> us).
> GPG> This is our project plan to support chpox in gomd:
> GPG> Phase#1:
> GPG> Start implementing basic support and providing some high-level APIs
> GPG> register/restore processes (maybe exported in "our" libgomd so
> GPG> can easily use them). The gomd daemon (written in C++ with STL) will
have a
> GPG> thread that periodically invokes the chpox register mechanism on the
> GPG> processes included in a appropriated list of PIDs. The thread will
> GPG> the needed calls sequentially (or we could start a separate thread
> GPG> per-process to be registered).
> GPG> Phase #2:
> GPG>  add some algorithms to choose automatically the processes to be
> GPG> (the user will be able to define what kind of process to be
registered via
> GPG> Thanks for your nice project.
> GPG> Keep up the good work!
> GPG> Gian Paolo Ghilardi (aka <rejected>)
> GPG> GOMD Team (http://www.nongnu.org/gomd/)
> --
> Best regards,
>  csaa                            mailto:address@hidden
>   http://www.cluster.kiev.ua
>   http://www.icc.univ.kiev.ua

reply via email to

[Prev in Thread] Current Thread [Next in Thread]