From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Serge E. Hallyn" Subject: Re: [PATCH 0/6] /proc/pid/checkpointable Date: Wed, 18 Mar 2009 12:18:40 -0500 Message-ID: <20090318171840.GA29523@us.ibm.com> References: <20090317062754.GA2377@us.ibm.com> <20090317063940.GF2377@us.ibm.com> <49C0B6FF.5030104@cs.columbia.edu> <20090318135953.GE22636@us.ibm.com> <49C1201A.3050604@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <49C1201A.3050604-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Oren Laadan Cc: Containers , Sukadev Bhattiprolu , "David C. Hansen" List-Id: containers.vger.kernel.org Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org): > > > Serge E. Hallyn wrote: > > Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org): > >> > >> Sukadev Bhattiprolu wrote: > >>> From: Sukadev Bhattiprolu > >>> Date: Fri, 13 Mar 2009 17:25:42 -0700 > >>> Subject: [PATCH 5/6] Define and use proc_pid_checkpointable() > >>> > >>> Create a proc file, /proc/pid/checkpointable, which shows '1' if > >>> task is checkpointable and '0' if it is not. > >>> > >>> To determine whether a task is checkpointable, the handler for this > >>> new proc file, shares the same code with sys_checkpoint(). > > > > Hey Oren, > > > > 3 counter-points: > > > >> I still don't understand why we would like to do it this way. > >> > >> First, it makes little sense to do it per-task, because we are supposed > >> to checkpoint an entire container. > > > > Yes we need per-container info too. Actually, per-checkpoint-job-init, > > so if we send pids in for that, it should return false if we send in the > > pid of a task which isn't a proper checkpoint-job-init. > > > > But we also want the info per-task, for debugging info. > > > > My suggestions works for this two: we add a flag CR_CTX_DRYRUN; a task > can ask to checkpoint itself, or another task, with CR_CTX_DRYRUN and > the checkpoint code runs without actual effect. (If we don't want to > expose the actual flag to userspace, then we simply use it in an > implementation of a /proc/PID/checkpointable operation). Hmm, so if we pass in CR_CTX_DRYRUN, then the fd can point to a file wherein to store a text represenation of the reason? Dave will probably hate it, but it could be worse... -serge