[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090306162337.GA3040@us.ibm.com>
Date: Fri, 6 Mar 2009 10:23:37 -0600
From: "Serge E. Hallyn" <serue@...ibm.com>
To: Dave Hansen <dave@...ux.vnet.ibm.com>
Cc: Alexey Dobriyan <adobriyan@...il.com>,
Christoph Hellwig <hch@...radead.org>,
containers <containers@...ts.linux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH 00/11] track files for checkpointability
Quoting Dave Hansen (dave@...ux.vnet.ibm.com):
> On Fri, 2009-03-06 at 08:34 -0600, Serge E. Hallyn wrote:
> > > > With time the amount of stuff C/R won't support will approach zero,
> > > > but the infrastructure for "checkpointable" will stay constant.
> > > > If it's too much right now, it will be way too much in future.
> > >
> > > What have you seen in OpenVZ? Do new things that are not checkpointable
> > > pop up very often?
> >
> > Realistically, do you think the uncheckpointable stuff would catch a
> > brand-new unsupported feature? If it has a file interface then I
> > suppose it would. Well, might. I wouldn't be surprised if the authors
> > would cut and paste enough code to paste the .checkpoint =
> > generic_file_checkpoint line :)
>
> Yeah, that's true. Us maintainers would probably need to keep an eye on
> that.
Which imo is fine, but my question is whether that leaves any actual
value in the persistent per-resource uncheckpointable flag.
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists