Date: Thu, 17 May 2012 12:05:41 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: linux-kernel@vger.kernel.org, Pavel Emelyanov <xemul@parallels.com>,
        James Bottomley <jbottomley@parallels.com>,
        linux-fsdevel@vger.kernel.org
Subject: Re: [rfc 0/4] procfs fdinfo extension
Message-Id: <20120517120541.f2dbdee9.akpm@linux-foundation.org>
In-Reply-To: <20120517160738.116113099@openvz.org>
References: <20120517160738.116113099@openvz.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1165
Lines: 27

On Thu, 17 May 2012 20:07:38 +0400
Cyrill Gorcunov <gorcunov@openvz.org> wrote:

> when we do restore files such as eventfd/eventpoll we need to pass
> appropriate parameters to system calls.

What does "such as" mean?  Provide the whole list, please.  I assume
we're going to have to add ~100 lines of stuff to each and every one? 
Stuff which, according to this patchset, is needed even when
CONFIG_CHECKPOINT_RESTORE=n?

My reason for disliking our whole approach to integration of c/r is
that it exposes us to an ongoing trickle of nasty surprises.  This
patchset is one such nasty surprise, and we don't even know how
extensive this particular surprise will be.

And how many more surprises are we going to get?


I'm quite apprehensive about this, largely because it has so many
unknowns.  How much work would it be to prepare a full list of
everything that still needs to be done to fully implement c/r in Linux?
--
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/