On Thu, 2009-03-05 at 20:40 +0300, Alexey Dobriyan wrote: > On Thu, Mar 05, 2009 at 08:38:57AM -0800, Dave Hansen wrote: > > This takes a suggestion of Ingo's along with comments from lots of > > other people. It can track whether a given file is able to be > > checkpointed. It introduces a f_op to allow easy customization > > like the reset of the VFS. > > Here is how alternative looks like > * without touching VFS at all > * without adding default handlers Are these bad things? If this was harmful to the VFS, I can bet Christoph would be speaking up. As far as the default handlers, blame Christoph. :) > * without duplicate code every ->checkpoint hook will have Well, I had actually planned to break the generic function up into a "common" function that all of the handlers can call or could be called before each handler. This is trivially fixable, but it would look kinda goofy without some code to use it. > * without largely useless "special file" messages > (what's so special about it?) Very true. I'll improve that one. > * without adding userspace-visible /proc/*/checkpointable Ingo, could you weigh in on how you expected this "checkpointable" flag to get exposed to and checked by userspace? > * without recalculating "checkpointable" property on fs_struct > on every C/R=y kernel. Yeah, this is certainly less than ideal. Although, I haven't seen your proposal for where to tie your code into the kernel. Do you suggest that we do nothing during normal kernel runtime and all the checking at sys_checkpoint() time? > * with "ban by default" policy as well > * with error message immediatly understandable by developer: > > cr_check_file: can't checkpoint file f61a0f40, ->f_op = socket_file_ops+0x0/0x1c0 That's a much better error message than I have. I think I'll steal it if you don't mind. > It may lack some printk, but printks are trivial to insert including > using d_path for precise info. This is definitely workable approach. However, could you show how you would support /dev/null and, say, /proc/$$/stat? I've shown what it takes to do that in my patches, and I think it would show a lot about your approach. -- Dave _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
