From: Dave Hansen <dave@linux.vnet.ibm.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
akpm@linux-foundation.org, containers@lists.linux-foundation.org,
xemul@parallels.com, mingo@elte.hu, orenl@cs.columbia.edu,
hch@infradead.org, torvalds@linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/30] cr: core stuff
Date: Tue, 14 Apr 2009 09:48:24 -0700 [thread overview]
Message-ID: <1239727704.32604.80.camel@nimitz> (raw)
In-Reply-To: <20090414154139.GA8085@us.ibm.com>
On Tue, 2009-04-14 at 10:41 -0500, Serge E. Hallyn wrote:
> > Module can legally support C/R for its files.
> > In the end it most certainly will end up with module registering restart
>
> Which module? The module defining a filesystem?
>
> In that case I'm just not clear on how the restart code will know which
> fs's file_operations to use to pick a fops->restart() fn.
There's not an f_op on the restart side -- there can't be. The problem
is that we get a CR_FD_FOO object and need to call off into the "foo"
code to recreate the 'struct file'. To me, that screams of a nice list
of function handlers indexed be CR_FD_FOO.
So, we have a list of these sitting around somewhere:
int restore_fd_func(struct cr_ctx *ctx, struct cr_fd_hdr *fd, void *private)
and when we see a CR_FD_HDR object, we look up its type and call the
respective handler. The handler will get enough data to go and restore
the fd. The fd number and other things common to all fds should be
present in the cr_fd_hdr.
-- Dave
next prev parent reply other threads:[~2009-04-14 16:48 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-10 2:35 [PATCH 10/30] cr: core stuff Alexey Dobriyan
2009-04-10 9:35 ` Ingo Molnar
2009-04-10 11:43 ` Alexey Dobriyan
2009-04-10 16:19 ` Brian Haley
2009-04-13 8:10 ` Alexey Dobriyan
2009-04-13 21:47 ` Serge E. Hallyn
2009-04-14 5:52 ` Oren Laadan
2009-04-14 15:29 ` Serge E. Hallyn
2009-04-14 16:37 ` "partial" container checkpoint Dave Hansen
2009-04-14 17:30 ` Kevin Fox
2009-04-15 0:06 ` Paul Menage
2009-04-14 15:27 ` [PATCH 10/30] cr: core stuff Alexey Dobriyan
2009-04-14 15:41 ` Dave Hansen
2009-04-14 16:57 ` Alexey Dobriyan
2009-04-14 15:41 ` Serge E. Hallyn
2009-04-14 16:48 ` Dave Hansen [this message]
2009-04-14 17:00 ` Alexey Dobriyan
2009-04-14 17:04 ` Alexey Dobriyan
2009-04-14 17:23 ` checkpoint/restart: taking refcounts on kernel objects Dave Hansen
2009-05-01 12:56 ` Alexey Dobriyan
2009-04-14 17:43 ` [PATCH 10/30] cr: core stuff Oren Laadan
2009-04-14 5:22 ` Oren Laadan
2009-04-14 16:00 ` Alexey Dobriyan
2009-04-14 16:39 ` Dave Hansen
2009-04-14 17:28 ` Alexey Dobriyan
2009-04-14 18:19 ` Oren Laadan
2009-04-14 19:00 ` Alexey Dobriyan
2009-04-14 19:26 ` Oren Laadan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1239727704.32604.80.camel@nimitz \
--to=dave@linux.vnet.ibm.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=orenl@cs.columbia.edu \
--cc=serue@us.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=xemul@parallels.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox