Date: Fri, 10 Oct 2008 16:59:34 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Daniel Lezcano <dlezcano@fr.ibm.com>
Cc: Greg Kurz <gkurz@fr.ibm.com>, Dave Hansen <dave@linux.vnet.ibm.com>,
       containers@lists.linux-foundation.org, arnd@arndb.de,
       linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 1/2] Track in-kernel when we expect
	checkpoint/restart to work
Message-ID: <20081010145934.GF11695@elte.hu>
References: <20081009190405.13A253CB@kernel> <1223626834.8787.8.camel@localhost.localdomain> <48EF144D.1050906@fr.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <48EF144D.1050906@fr.ibm.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1149
Lines: 28


* Daniel Lezcano <dlezcano@fr.ibm.com> wrote:

>> By the way, why don't you introduce the reverse operation ?
>
> I think implementing the reverse operation will be a nightmare, IMHO 
> it is safe to say we deny checkpointing for the process life-cycle 
> either if the created resource was destroyed before we initiate the 
> checkpoint.

it's also a not too interesting case. The end goal is to just be able to 
checkpoint everything that matters - in the long run there simply wont 
be many places that are marked 'cannot checkpoint'.

So the ability to deny a checkpoint is a transitional feature - a 
flexible CR todo list in essence - but also needed for 
applications/users that want to rely on CR being a dependable facility.

It would be bad for most of the practical usecases of checkpointing to 
allow the checkpointing of an app, just to see it break on restore due 
to lost context.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/