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

["Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Quoting 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?

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.

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?  :)

-serge