On Mon, 2009-03-02 at 07:37 -0600, Serge E. Hallyn wrote: > Quoting Dave Hansen (dave@xxxxxxxxxxxxxxxxxx): > > > > Introduce a files_struct counter to indicate whether a particular > > file_struct has ever contained a file which can not be > > checkpointed. This flag is a one-way trip; once it is set, it may > > not be unset. > > > > We assume at allocation that a new files_struct is clean and may > > be checkpointed. However, as soon as it has had its files filled > > from its parent's, we check it for real in __scan_files_for_cr(). > > At that point, we mark it if it contained any uncheckpointable > > files. > > > > We also check each 'struct file' when it is installed in a fd > > slot. This way, if anyone open()s or managed to dup() an > > unsuppored file, we can catch it. > > > > Signed-off-by: Dave Hansen <dave@xxxxxxxxxxxxxxxxxx> > > So on a practical note, Ingo's scheme appears to be paying off. In > order for any program's files_struct to be checkpointable right now, > it must be statically compiled, else ld.so (I assume) looks up > /proc/$$/status. So since proc is not checkpointable, the result > is irreversibly non-checkpointable. > > So... does it make sense to mark proc as checkpointable? Do we > reasonably assume that the same procfile will be available at > restart? Can I kick and scream for a minute? :) dave@nimitz:~/lse/linux/2.5/linux-2.6.git$ grep -r 'struct file_operations.*{' fs/ | grep /proc/ | wc -l 51 I'll need to go actually look at (and mark) each of those. But, the upside is that I'll have to go look at each of those. -- Dave _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers