Oren Laadan <orenl@xxxxxxxxxxxxxxx> writes: > I think it's useful to be able to > > 1) checkpoint on a system with !CONFIG_UTS_NS, and - > 2) checkpoint on a system with CONFIG_UTS_NS and restart on a > system with !CONFIG_UTS_NS (as long as all tasks in the image > share a single uts-ns) In principle I agree, but what confidence can we have that meaningful testing of such configurations (especially #2) will occur? Flexibility is good, but the complexity involved in properly supporting checkpoint with all possible combinations of CONFIG_*_NS seems daunting. Just consider the build matrix (assuming CONFIG_CHECKPOINT=y): +------ CONFIG_CGROUP_NS |+----- CONFIG_UTS_NS ||+---- CONFIG_IPC_NS |||+--- CONFIG_NET_NS ||||+-- CONFIG_USER_NS |||||+- CONFIG_PID_NS nnnnnn ynnnnn yynnnn yyynnn yyyynn yyyyyn .... nynnnn nyynnn nyyynn nyyyyn nyyyyy ... You get the idea, I'm sure: at least 64 distinct build configurations that are salient to checkpoint. Is anybody building even a fraction of those? Add actual runtime testing of C/R to that workload and it quickly becomes impractical to achieve decent test coverage. And accommodating C/R between kernels with different CONFIG_*_NS settings introduces a combinatorial explosion of scenarios to test. CONFIG_CHECKPOINT should just depend on all of CONFIG_*_NS. Otherwise we're going to have an abundance of corner cases at build time and (more importantly) run time that never get exercised. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
