On Mon, Jan 17, 2005 at 06:31:06PM -0800, Peter Kieser wrote:
I have no problem with bringing up the discussion of process
checkpointing on FreeBSD, what I _DO_ have a problem with is all this
cruft about DF on the list all the time. We keep getting the, DragonFly
does it this way or
If you guys are interested in the checkpointing code, now is the time
to port it. And maybe someone could donate the last little bit required
to make it reasonably secure when used by a non-root user. That bit being
to have the kernel record the file handles and creds in a
I have no problem with bringing up the discussion of process
checkpointing on FreeBSD, what I _DO_ have a problem with is all this
cruft about DF on the list all the time. We keep getting the, DragonFly
does it this way or DragonFly has this and we don't on the
freebsd-hackers mailing list,
Peter Kieser wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
I have no problem with bringing up the discussion of process
checkpointing on FreeBSD, what I _DO_ have a problem with is all this
cruft about DF on the list all the time. We keep getting the, DragonFly
does it this way
On Thu, Jan 13, 2005 at 10:00:29PM -0800, Peter Kieser wrote:
freebsd-hackers != DragonFly BSD Mailing List...
--Peter
I'd also agree further discussion on DragonFly's checkpoint facility
be taken to DragonFly lists unless/until FreeBSD decides on
implementing a similar framework. That was the
Zaphod Beeblebrox [EMAIL PROTECTED] writes:
Having a process (or full system) checkpoint facility would make the
implementation of suspend-to-disk rather trivial --- which is a much
desired feature.
I would definitely use such a feature if it was added to FreeBSD.
--
Christian Laursen
On Wed, Jan 12, 2005 at 01:40:02PM -0800, Brooks Davis wrote:
On Wed, Jan 12, 2005 at 02:17:38PM -0700, Siddharth Aggarwal wrote:
I am responding to a post back in Oct 2003 when the checkpointing feature
was announced for DragonFly. I have been doing some research on this, and
have seen
--- Allan Fields [EMAIL PROTECTED] wrote:
On Wed, Jan 12, 2005 at 01:40:02PM -0800, Brooks
Davis wrote:
On Wed, Jan 12, 2005 at 02:17:38PM -0700,
Siddharth Aggarwal wrote:
I am responding to a post back in Oct 2003 when
the checkpointing feature
was announced for DragonFly. I
Having a process (or full system) checkpoint facility would make the
implementation of suspend-to-disk rather trivial --- which is a much
desired feature.
___
freebsd-hackers@freebsd.org mailing list
freebsd-hackers != DragonFly BSD Mailing List...
--Peter
Siddharth Aggarwal wrote:
Hi all,
I am responding to a post back in Oct 2003 when the checkpointing feature
was announced for DragonFly. I have been doing some research on this, and
have seen some projects that use Xen VMM to achieve
Hi all,
I am responding to a post back in Oct 2003 when the checkpointing feature
was announced for DragonFly. I have been doing some research on this, and
have seen some projects that use Xen VMM to achieve checkpoints of guest
OSes.
So I was looking for inputs from people as to what everyone
I've promised Nate to port the functionality to FreeBSD. I'm busy doing some
things with the FreeBSD port to Xen at the moment.
Checkpointing a process is intrinsically messy for reasons beyond the obvious
statefulness of TCP connections. Process state, particularly with regard to
devices, is
On Wed, Jan 12, 2005 at 02:17:38PM -0700, Siddharth Aggarwal wrote:
I am responding to a post back in Oct 2003 when the checkpointing feature
was announced for DragonFly. I have been doing some research on this, and
have seen some projects that use Xen VMM to achieve checkpoints of guest
Thanks for your reply.
I understand the complexity of checkpointing a process and I do agree that
capturing the complete state of a system is really difficult. So my
question is that if a subset of that functinality was to be implemented
(e.g. not guaranteeing certain things to processes when
Taking this off list.
-Kip
On Wed, 12 Jan 2005, Siddharth Aggarwal wrote:
Thanks for your reply.
I understand the complexity of checkpointing a process and I do agree that
capturing the complete state of a system is really difficult. So my
question is that
You seem to have mistaken [EMAIL PROTECTED] for [EMAIL PROTECTED]
Thank you Poul for taking the time to correct me. Although checkpointing
was a specifically requested feature for FreeBSD, it was, given the
circumstances, an unforgivable error for me to announce it on a FreeBSD
list. The module
On Mon, Oct 20, 2003 at 01:52:07PM -0700, Kip Macy wrote:
Please note that there are *SEVERE* security issues with this module.
The module is not loaded into the kernel by default and, when loaded,
can only be used by users in the wheel group.
Why the wheel group? Until now, the only special
On Tue, Oct 21, 2003 at 09:30:38AM -0700, Kris Kennaway wrote:
Please note that there are *SEVERE* security issues with this module.
The module is not loaded into the kernel by default and, when loaded,
can only be used by users in the wheel group.
Why the wheel group? Until now, the
At BSDCon '03 it was mentioned that a process checkpoint / restore
facility would be a useful addition to FreeBSD. This post is to
announce that Matt and I have added such a facility to DragonFly BSD.
It is noteworthy for -hackers as anyone who is interested could still
port it with relative
The impacted files are in the directories sys/checkpt and usr.bin/checkpt
as well as sys/kern/imgact_elf.c and sys/kern/kern_fp.c.
-Kip
___
[EMAIL PROTECTED] mailing list
I've lived through several checkpointing implementations. You've got the easy
part. Applications must participate or such a facility has very limited
usefulness. Delivering a signal is only part of the problem; there tend to
be issues synchronizing user-mode checkpoint of application state
:I've lived through several checkpointing implementations. You've got the easy
:part. Applications must participate or such a facility has very limited
:usefulness. Delivering a signal is only part of the problem; there tend to
:be issues synchronizing user-mode checkpoint of application
22 matches
Mail list logo