Re: [PATCH] unshare: Cleanup up the sys_unshare interface beforewe are committed.

[Janak Desai]

Eric W. Biederman wrote:

> Linus Torvalds <torvalds@xxxxxxxx> writes:
>
>  
>
> > On Fri, 17 Mar 2006, Michael Kerrisk wrote:
> >    
> >
> > > > - it's all the same issues that clone() has
> > > >        
> > > At the moment, but possibly not in the future (if one day
> > > usnhare() needs a flag that has no analogue in clone()).
> > >      
> > I don't believe that.
> >
> > If we have something we might want to unshare, that implies by definition 
> > that it was something we wanted to conditionally share in the first place.
> >
> > IOW, it ends up being something that would be a clone() flag.
> >
> > So I really do believe that there is a fundamental 1:1 between the flags. 
> > They aren't just "similar". They are very fundamentally about the same 
> > thing, and giving two different names to the same thing is CONFUSING.
> >    
>
> The scary thing is that with only 7 things we can share or not,
> and a 32bit field we have only 7 bits left that we can define.
> Last count I think I know of at least that many additional global
> namespaces in the kernel.
>
>
>
> On the confusing side.  Unshare largely because it doesn't default to
> unsharing all of the thread state.  Has the weird issue that unshare
> will automatically add bits you didn't ask for (so it can satisfy your
> request) and unsharing more than you requested.  Clone when presented
> with the same situation returns an error.
>  
We are probably digressing from the original discussion but just wanted to
point out that the situations presented to clone and unshare are a bit 
different.
Clone returns an error because in the same call you are trying to provide
illegal combination of flags. Like saying that you want a new namespace
but want to share the filesystem. There is no way for clone to know which
of the two flags to honor or ignore. Where as with unshare if you are
trying to unshare namespace but are currently sharing filesystem, then
it is possible to complete the request by unsharing filesystem as well .
You may remember that the earlier incarnation of the unshare patch did
return an error. However it was pointed out, and correctly so, that it is
better to unshare appropriate related contexts.

-Janak

> So even while the resources are the same the interaction of the
> bits really is quite different between the two calls.
>
> Eric
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/