public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oren Laadan <orenl@cs.columbia.edu>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>,
	containers@lists.linux-foundation.org, jeremy@goop.org,
	arnd@arndb.de, linux-kernel@vger.kernel.org
Subject: Re: [RFC v2][PATCH 4/9] Memory management - dump state
Date: Sun, 31 Aug 2008 03:16:31 -0400	[thread overview]
Message-ID: <48BA454F.7050308@cs.columbia.edu> (raw)
In-Reply-To: <1219870576.8680.96.camel@nimitz>


Dave, Serge:

I'm currently away so I must keep this short. I think we have so far
more discussion than an actual problem. I'm happy to coordinate with
every interested party to eventually see this work go into main stream.

My only concerns are twofold: first, to get more feedback I believe we
need to get the code a bit more usable; including FDs is an excellent
way to actually do that. That will add significant value to the patch.
I think it's important to demonstrate how shared resources and multiple
processes are handled. FDs demonstrate the former (with a fixed version
of the recent patchset - I will post soon). The latter will increase
the size of the patchset significantly, so perhaps can indeed wait for
now.

It should not be hard for me to add functionality on top of a more
basic patchset. The question is, what is "basic" ?  Anyway, I will be
back towards the end of the week. Let's try to discuss this over IRC
then (e.g. Friday afternoon ?).

Oren.

Dave Hansen wrote:
> On Wed, 2008-08-27 at 15:48 -0500, Serge E. Hallyn wrote:
>> Quoting Dave Hansen (dave@linux.vnet.ibm.com):
>>> On Wed, 2008-08-27 at 15:34 -0500, Serge E. Hallyn wrote:
>>>> (Or, is that too much effort required on your part to try and
>>>> cherrypick bits of Oren's changes back into your tree?)
>>> That would probably work as long as Oren is working on top of what I
>>> have.  It's going to be a lot harder if I have to repeat the same
>>> break-out process for each iteration of Oren's patches, though.
>>>
>> If Oren's purpose is not quite to create a upstreamable patchset,
>> then it would make more sense for him to keep a git tree and
>> put new patches on top of his existing ones (within reaason as he
>> rebases).  Then you'd at least be able to trivially look at the latest
>> deltas.
> 
> The trick would be compromising on things that I, for instance, think
> need to be rewritten or removed.
> 
> Oren would have to rebase his work against what I do.  I guess you could
> think about it like me being upstream from Oren.  Anything that I would
> change, Oren would need to rebase on top of.
> 
> Oren, are you willing to keep a set of patches that add functionality on
> top of a minimal set that I'm keeping?  Mine being the set that we're
> trying to push into mainline as soon as possible.
> 
> -- Dave
> 
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers

  reply	other threads:[~2008-08-31  7:17 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-21  2:58 [RFC v2][PATCH 1/9] kernel based checkpoint-restart Oren Laadan
2008-08-21  3:03 ` [RFC v2][PATCH 1/9] Create trivial sys_checkpoint/sys_restart syscalls Oren Laadan
2008-08-21  5:17   ` Oren Laadan
2008-08-22 19:32   ` Dave Hansen
2008-08-22 20:11     ` Dave Hansen
2008-08-22 21:20     ` Oren Laadan
2008-08-21  3:04 ` [RFC v2][PATCH 2/9] General infrastructure for checkpoint restart Oren Laadan
2008-08-21  9:35   ` Louis Rilling
2008-08-24  5:58     ` Oren Laadan
2008-08-22 20:01   ` Dave Hansen
2008-08-25  2:47     ` Oren Laadan
2008-08-26 16:42       ` Dave Hansen
2008-08-27  0:38         ` Oren Laadan
2008-08-21  3:04 ` [RFC v2][PATCH 3/9] x86 support for checkpoint/restart Oren Laadan
2008-08-22 20:17   ` Dave Hansen
2008-08-21  3:05 ` [RFC v2][PATCH 4/9] Memory management - dump state Oren Laadan
2008-08-21  7:30   ` Ingo Molnar
2008-08-21  8:01     ` Justin P. Mattock
2008-08-21 10:28     ` Balbir Singh
2008-08-21 11:59       ` Ingo Molnar
2008-08-21  9:53   ` Louis Rilling
2008-08-22 21:21     ` Oren Laadan
2008-08-22 20:37   ` Dave Hansen
2008-08-24  5:40     ` Oren Laadan
2008-08-26 16:33       ` Dave Hansen
2008-08-27  0:14         ` Oren Laadan
2008-08-27 15:41           ` Dave Hansen
2008-08-27 15:57             ` Louis Rilling
2008-08-27 16:12               ` Dave Hansen
2008-08-27 16:19                 ` Jeremy Fitzhardinge
2008-08-27 20:34             ` Serge E. Hallyn
2008-08-27 20:38               ` Dave Hansen
2008-08-27 20:48                 ` Serge E. Hallyn
2008-08-27 20:56                   ` Dave Hansen
2008-08-31  7:16                     ` Oren Laadan [this message]
2008-08-31 17:34                       ` Cedric Le Goater
2008-09-03 11:43                         ` [Devel] " Andrey Mirkin
2008-09-03 12:15                           ` Cedric Le Goater
2008-09-03 13:29                             ` Andrey Mirkin
2008-09-02 15:32                       ` Serge E. Hallyn
2008-08-21  3:05 ` [RFC v2][PATCH 5/9] Memory managemnet - restore state Oren Laadan
2008-08-21 10:07   ` Louis Rilling
2008-08-21  3:06 ` [RFC v2][PATCH 6/9] Checkpoint/restart: initial documentation Oren Laadan
2008-08-21  3:06 ` [RFC v2][PATCH 7/9] Infrastructure for shared objects Oren Laadan
2008-08-21 10:40   ` Louis Rilling
2008-08-26 17:01     ` Dave Hansen
2008-08-27  8:26       ` Louis Rilling
2008-08-21  3:07 ` [RFC v2][PATCH 8/9] File descriprtors - dump state Oren Laadan
2008-08-21 11:06   ` Louis Rilling
2008-08-25  3:28     ` Oren Laadan
2008-08-25 10:30       ` Louis Rilling
2008-08-21  3:07 ` [RFC v2][PATCH 9/9] File descriprtors (restore) Oren Laadan
2008-08-21  5:26   ` Oren Laadan
2008-08-21  5:15 ` [RFC v2][PATCH 1/9] kernel based checkpoint-restart 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=48BA454F.7050308@cs.columbia.edu \
    --to=orenl@cs.columbia.edu \
    --cc=arnd@arndb.de \
    --cc=containers@lists.linux-foundation.org \
    --cc=dave@linux.vnet.ibm.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=serue@us.ibm.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