Pavel Machek wrote:
Hi!
I have to wonder if this is just a symptom of us trying to do this the
wrong way. We're trying to talk the kernel into writing internal gunk
into a FD. You're right, it is like a splice where one end of the pipe
is in the kernel.
Any thoughts on a better way to
Oren Laadan wrote:
Dave Hansen wrote:
On Fri, 2008-08-08 at 11:46 +0200, Arnd Bergmann wrote:
On Friday 08 August 2008, Dave Hansen wrote:
+ hh-magic = 0x00a2d200;
+ hh-major = (LINUX_VERSION_CODE 16) 0xff;
+ hh-minor = (LINUX_VERSION_CODE 8) 0xff;
+ hh-patch =
Hi!
I have to wonder if this is just a symptom of us trying to do this the
wrong way. We're trying to talk the kernel into writing internal gunk
into a FD. You're right, it is like a splice where one end of the pipe
is in the kernel.
Any thoughts on a better way to do
On Thu, 2008-08-14 at 07:53 +0200, Pavel Machek wrote:
As Oren has pointed out before, passing in an fd means we can pass a
socket into the syscall.
If you do pass a socket, will it handle blocking correctly? Getting
deadlocked task would be bad. What happens if I try to snapshot into
On Thu, 2008-08-14 at 12:09 +0400, Pavel Emelyanov wrote:
E.g. consider we are saving a container image on ipv6 node and trying
to restore from it on the one without the ipv6. In that case we *may*
have some object of for example CKPT_IPV6_IFA type of CLPT_IPV6_SOCK_INFO
and fail the
Quoting Arnd Bergmann ([EMAIL PROTECTED]):
On Friday 08 August 2008, Dave Hansen wrote:
On Fri, 2008-08-08 at 11:46 +0200, Arnd Bergmann wrote:
+struct cr_hdr_tail {
+ __u32 magic;
+ __u32 cksum[2];
+};
This structure has an odd multiple of 32-bit members,
On Monday 11 August 2008, Serge E. Hallyn wrote:
One reason is that I suspect that stops us from being able to send that
data straight to a pipe to compress and/or send on the network, without
hitting local disk. Though if the checkpointfs was ram-based maybe not?
As Oren has pointed out
Quoting Dave Hansen ([EMAIL PROTECTED]):
On Sat, 2008-08-09 at 00:13 +0200, Arnd Bergmann wrote:
I have to wonder if this is just a symptom of us trying to do this the
wrong way. We're trying to talk the kernel into writing internal gunk
into a FD. You're right, it is like a splice
On Monday 11 August 2008, Serge E. Hallyn wrote:
At the restart end, every resource which was checkpointed will have to
be re-created, and permissions checked against the privilege of the
task which did the restart. We may end up having to make use of the new
credentials for this.
This
On Mon, 2008-08-11 at 18:53 +0200, Arnd Bergmann wrote:
The best way I can think of for this would be to use existing syscalls
(e.g. sched_setscheduler, setfsuid, ...) from user space whereever
possible and do only the bare minimum for the restart part in the
kernel.
Well, the current
I'm trying to figure out this patch set...here's a few things which
have caught my eye in passing.
+/**
+ * cr_get_fname - return pathname of a given file
+ * @file: file pointer
+ * @buf: buffer for pathname
+ * @n: buffer length (in) and pathname length (out)
+ *
+ * if the buffer
On Mon, 2008-08-11 at 12:03 -0600, Jonathan Corbet wrote:
I'm trying to figure out this patch set...here's a few things which
have caught my eye in passing.
+/**
+ * cr_get_fname - return pathname of a given file
+ * @file: file pointer
+ * @buf: buffer for pathname
+ * @n: buffer
Dave Hansen wrote:
On Mon, 2008-08-11 at 12:03 -0600, Jonathan Corbet wrote:
I'm trying to figure out this patch set...here's a few things which
have caught my eye in passing.
+/**
+ * cr_get_fname - return pathname of a given file
+ * @file: file pointer
+ * @buf: buffer for pathname
+
On Saturday 09 August 2008, Dave Hansen wrote:
On Sat, 2008-08-09 at 00:39 +0200, Arnd Bergmann wrote:
The main problem I see with that would be atomicity: If you want multiple
processes to keep interacting with each other, you need to save them at
the same point in time, which gets harder
On Sat, 2008-08-09 at 08:37 +0200, Arnd Bergmann wrote:
On Saturday 09 August 2008, Dave Hansen wrote:
On Sat, 2008-08-09 at 00:39 +0200, Arnd Bergmann wrote:
The main problem I see with that would be atomicity: If you want multiple
processes to keep interacting with each other, you need
On Friday 08 August 2008, Dave Hansen wrote:
+/* write the checkpoint header */
+static int cr_write_hdr(struct cr_ctx *ctx)
+{
+ struct cr_hdr h;
+ struct cr_hdr_head *hh = ctx-tbuf;
+ struct timeval ktv;
+
+ h.type = CR_HDR_HEAD;
+ h.len = sizeof(*hh);
+ h.id =
On Fri, 2008-08-08 at 11:46 +0200, Arnd Bergmann wrote:
On Friday 08 August 2008, Dave Hansen wrote:
+ hh-magic = 0x00a2d200;
+ hh-major = (LINUX_VERSION_CODE 16) 0xff;
+ hh-minor = (LINUX_VERSION_CODE 8) 0xff;
+ hh-patch = (LINUX_VERSION_CODE) 0xff;
...
+}
Do you rely
Dave Hansen wrote:
On Fri, 2008-08-08 at 11:46 +0200, Arnd Bergmann wrote:
On Friday 08 August 2008, Dave Hansen wrote:
+ hh-magic = 0x00a2d200;
+ hh-major = (LINUX_VERSION_CODE 16) 0xff;
+ hh-minor = (LINUX_VERSION_CODE 8) 0xff;
+ hh-patch = (LINUX_VERSION_CODE) 0xff;
...
On Friday 08 August 2008, Dave Hansen wrote:
On Fri, 2008-08-08 at 11:46 +0200, Arnd Bergmann wrote:
+struct cr_hdr_tail {
+ __u32 magic;
+ __u32 cksum[2];
+};
This structure has an odd multiple of 32-bit members, which means
that if you put it into a larger structure that
On Fri, 2008-08-08 at 16:59 -0400, Oren Laadan wrote:
To avoid repetitive malloc/free, ctx-hbuf is a buffer to host headers
as they are read;
kmalloc/kfree() area really, really fast. I wonder if the code gets
easier or harder to read if we just alloc/free as we need to.
How large are these
On Friday 08 August 2008, Oren Laadan wrote:
Yeah, this is very true. My guess is that we'll need something like
what we do with modversions.
Exactly. The header should eventually contain sufficient information
to describe the kernel version, configuration, compiler, cpu (arch and
On Sat, 2008-08-09 at 00:13 +0200, Arnd Bergmann wrote:
I have to wonder if this is just a symptom of us trying to do this the
wrong way. We're trying to talk the kernel into writing internal gunk
into a FD. You're right, it is like a splice where one end of the pipe
is in the kernel.
On Saturday 09 August 2008, Dave Hansen wrote:
On Sat, 2008-08-09 at 00:13 +0200, Arnd Bergmann wrote:
Maybe you can invert the logic and let the new syscalls create a file
descriptor, and then have user space read or splice the checkpoint
data from it, and restore it by writing to the
23 matches
Mail list logo
