"Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > Quoting Nathan Lynch (ntl@xxxxxxxxx): >> 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? > > History says, low confidence. So far just 1 is bad enough. It's > taking a lot of my time on the LSM c/r (with the various combinations > of CONFIG_SECURITY, CONFIG_IPC_NS, and CONFIG_CHECKPOINT), and things > like CONFIG_IPC_NS consistently break c/r anyway. > > So for 2 i'm tempted to say let's encode a sha1sum of the .config > into the checkpoint header. We'll keep *trying* to support (2), and > userspace can trivially rewrite the header if it really wants to believe > we've succeeded. Are you suggesting having sys_restart code path consult the .config sha1sum in the image? Or is it just for the benefit of userspace? If the former, I'm having difficulty grasping the benefit. > > And for 1, I agree - most distros ship with namespaces enabled > anyway, and one day I expect we'll get rid of those configs, so > I see no reason to support CONFIG_CHECKPOINT if any namespaces are > turned off. > > In fact, I thought that last week Dave suggested that, and Nathan > was against it? :) I was against using select in the CHECKPOINT config item to force-enable CONFIG_*_NS. Making CHECKPOINT depend on the namespace options strikes me as a sane tradeoff here. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
