On Fri, Jun 5, 2009 at 12:41 PM, Serge E. Hallyn <serue@xxxxxxxxxx> wrote: > Quoting Andrew G. Morgan (morgan@xxxxxxxxxx): > ... >> > Now you mention using kernel_cap_t's... we can go partway >> > down that road, but the inherent problem is serializing the >> > relevant data so it can be streamed to some file. So I >> > think it's better if the subsystems are required to specify >> > a useful format (like struct ckpt_capabilities) and define >> > the checkpoint/restart helpers to serialize data into the >> > struct. We can try and get cute with dual mirrored >> > struct defs, one which is defined in terms the caps code >> > can understand, and one defined in more arch-independent >> > terms (which is why we need __u64s and packed, for instance). >> > But that seems more fragile than having clear and simple >> > requirements for the $SUBYSTEM_checkpoint() and $SUBSYSTEM_restart() >> > helpers. >> >> I like this $SUBSYSTEM_checkpoint() etc. thing. >> >> I like the ckpthdr.sed thing. I think a similar rule could be used to >> generate the calls to the list of $SUBSYSTEM_checkpoint() functions. > > Sorry, I don't follow. Could you say a bit more about this? See sketch below. > >> For serialization, could a kernel "gcc -E checkpoint-headers.h > >> this-kernel-checkpoint-file.h" build rule be enough? > > Again, I don't follow. Do you mean to turn something like kernel_cap_t > into something like struct ckpt_capabilities? Yes, but without manual effort. To return the the 1,2,3 breakdown. I think it should be possible for 1 to provide code like this: $SUBSYSTEM_header.h: struct ckpt_$SUBSYSTEM_s { kernel_foo_t a, b, c; }; $SUBSYSTEM_code.c: void $SUBSYSTEM_checkpoint(struct *storage_ptr) { } int $SUBSYSTEM_restore(struct *storage_ptr) { } 2 would be 'sed'(perl) generated: temp_header.h: foreach $x (sort @SUBSYSTEMS) { print "#include <$SUBSYSTEM_header.h>\n"; } print "extern full_checkpoint();\n"; print "struct uber_ckpt_struct {\n"; foreach $x (sort @SUBSYSTEMS) { print " struct ckpt_$x_s $x;\n"; } print <<EOT; }; #ifdef __kernel_source__ full_checkpoint() { EOT foreach $x (sort @SUBSYSTEMS) { print " $x_checkpoint();\n"; } print <<EOT; } #endif EOT "ditto for restore, but pay attention to return codes". Then, for '3', gcc -E temp_header.h | sed 'cut from line after 'extern full_checkpoint'. That means: 1. gets to define its checkpoint state with its own conventions 2. gets generated with some perl/sed/whatever - low maintenance 3. gets a plain C serialization of the checkpointed state. The kernel code subsystem code is king here. It defines its checkpoints in whatever manner it feels is natural for the specific subsystem. The glue code is autogenerated. User space has full access to the data in a plain C format. The user space code is where things are fragile, if the user space code wants to manipulate the checkpointed data in some way, but I think there will always be at least one place in the system for fragility and user space is the best place for it. Cheers Andrew > > thanks, > -serge > -- > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers