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? > 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? thanks, -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
