Re: [PATCH] [RFC] c/r: Add UTS support

["Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>]

Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> > What is wrong with Alexey's patch, which simply passes in the values
> > themselves?  Do you have another use in mind for the min/max pid
> > values?
> 
> At an implementation level (and I need to look at Alexey's specific patch)
> every patch I have seen to date creates their own version of alloc_pidmap.

You're right, Alexey's patch creates a new one.

> alloc_pidmap already implicitly takes min/max and first value to try
> as parameters.  RESERVED_PIDS, pid_max, and pid_ns->last_pid.  So
> instead of rewriting alloc_pidmap we should just be able to refactor
> alloc_pidmap to take the requisite values.  That should be less code
> and easier to maintain.

Yeah, that sounds good actually.  Thanks.

> Looking at the current implementation we also have the issue that
> pid_max is not per pid namespace.  Where it seems to belong.

Eh.  It does seem to, but otoh why give userspace knobs it has no use
for...  Or, can you think of a case where it'd be useful?

> >> If the primary use for a userspace interface is restart I feel we are
> >> doing it wrong.
> >
> > I think that's a good guideline, bad rule.  Certainly possible
> > that you're right that this is just pointing to in-kernel
> > recreation of process tree as the way to go.  I was getting
> > that feeling myself, but then there are still very good reasons
> > not to do that, as there are things which each task should do
> > before completing sys_restart() which are best done in userspace.
> > These include for instance creating virtual nics, and calling
> > Oren's suggested 'cr_advise()' system calls.
> 
> You might be right.   I am behind on that part of the conversation.
> 
> My general concern is that dividing up the responsibilities between user space
> and kernel space seems harder to maintain, and refactor if we don't get something
> right the first time.

So far we're actually still at the point where the code (Oren's set)
could go either way.  A small patch from Alexey can make it swing toward
kernel, while Oren's mktree.c userspace restart program swings the other
way.

And since we're punting on any nested namespaces it actually may stay that way
for awhile.

thanks,
-serge