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

[Jamie Lokier]

JANAK DESAI 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.
> >
> > 
> CLONE_FS unset for unshare doesn't mean that share the fs_struct with
> others. It just means that you leave the fs_struct alone (which may or
> maynot be shared). I agree that it is confusing, but I am having difficulty
> in seeing this reversal of flag meaning. clone creates a second task and
> allows you to pick what you want to share with the parent. unshare allows
> you to pick what you don't want to share anymore. The "what" in both
> cases can be same and still you can end up with a task with "share" state
> for a perticular structure. 

> For example, if we #define  FS   CLONE_FS,
> then clone(FS) will imply that you want to share fs_struct but unshare(FS)
> will imply that we want to unshare fs_struct.

Right.

But clone(CLONE_NEWNS) and unshare(CLONE_NEWNS) _don't_ behave like
that: clone(CLONE_NEWNS) unshares ns, and unshare(CLONE_NEWNFS) _also_
unshares ns.

That is the inconsistency: some flags to clone() mean "keep sharing
this thing", and some flags mean "make a new instance of this thing".
It's not your fault that clone() has that inconsistency.  It's because
clone() needs to treat a value of 0 for any bit as the historically
default behaviour.

Like clone(), unshare() will have to change from year to year, as new
flags are added.  It would be good if the default behaviour of 0 bits
to unshare() also did the right thing, so that programs compiled in
2006 still function as expected in 2010.  Hmm, this
forward-compatibility does not look pretty.

-- Jamie
-
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/