Re: [PATCH -mm 1/9] unshare system call: system call handler function

[JANAK DESAI <janak@us.ibm.com>]

Jamie Lokier wrote:

> Eric W. Biederman wrote:
>  
>
> > I follow but I am very disturbed.
> >
> > You are leaving CLONE_NEWNS to mean you want a new namespace.
> >
> > For clone CLONE_FS unset means generate an unshared fs_struct
> >          CLONE_FS set   means share the fs_struct with the parent
> >
> > But for unshare CLONE_FS unset means share the fs_struct with others
> >            and CLONE_FS set   means generate an unshared fs_struct
> >
> > The meaning of CLONE_FS between the two calls in now flipped,
> > but CLONE_NEWNS is not.  Please let's not implement it this way.
> >    
>
> I agree.
>
>  
>
> > Part of the problem is the double negative in the name, leading
> > me to suggest that sys_share might almost be a better name.
> >    
>
> I agree with that suggestion, too.
>
> Alternatively, we could just add a flag to clone(): CLONE_SELF,
> meaning don't create a new task, just modify the properties of the
> current task.
>  
... and this won't cause confusion :-) ? Clone to me implies that a second
entity is being created.

>  
>
> > So please code don't invert the meaning of the bits.  This will
> > allow sharing of the sanity checks with clone.
> > In addition this leaves open the possibility that routines like
> > copy_fs properly refactored can be shared between clone and unshare.
> >    
>
> And also make the API less confusing to document and use.
>
> -- Jamie
>
>  
I am all for less confusing API and saner semantics. I will take a look
at yours and Eric's suggestions to see what can be done.

Thanks.

-Janak

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