Re: [PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n

[Nathan Lynch <ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>]

Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> 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.