From: JANAK DESAI <janak@us.ibm.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
viro@ftp.linux.org.uk, chrisw@osdl.org, dwmw2@infradead.org,
serue@us.ibm.com, mingo@elte.hu, linuxram@us.ibm.com,
jmorris@namei.org, sds@tycho.nsa.gov, akpm@osdl.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm 1/9] unshare system call: system call handler function
Date: Thu, 15 Dec 2005 23:35:05 -0500 [thread overview]
Message-ID: <43A243F9.7040600@us.ibm.com> (raw)
In-Reply-To: <20051215212845.GA6990@mail.shareable.org>
Jamie Lokier wrote:
>JANAK DESAI wrote:
>
>
>>clone checks to
>>makes sure that CLONE_NEWNS and CLONE_FS are not specified together, while
>>unshare will force CLONE_FS if CLONE_NEWNS is spefcified.
>>
>>
>[ ... ]
>
>
>>since clone and unshare are doing opposite things, sharing code
>>between them that checks constraints on the flags can get
>>convoluted.
>>
>>
>
>clone() and unshare() are not doing opposite things. They do the same
>thing, which is to unshare some properties while keeping others
>shared, and the only differences are that clone() first creates a new
>task, and the defaults for flags that aren't specified.
>
>
>
Well .. by opposite I meant one allows you to share specific contexts while
the other allows you to unshare specific contexts. In case of clone, by not
specifying flags you can also unshare, however the same is not true for
the unshare system call. That is, if you don't specify a flag, that
structure
is left alone in its current state. It does not become shared if it was
not being
shared to begin with.
>It is the polarity of _some_ flags which is opposite in your unshare()
>API: In your API, CLONE_FS means "unshare fs", while with clone() it
>means "share fs". Same for other flags - except for CLONE_NEWNS,
>where unshare() and clone() both take it to mean "unshare ns".
>
>That's a bit of a confusing mixture of polarities, in my opinion.
>
>I think it would be better if this:
>
> pid = clone(flags);
>
>Could be always equivalent to this:
>
> pid = clone(CLONE_FLAGS_TO_SHARE_EVERYTHING)
> if (pid == 0)
> unshare(flags);
>
>Or, if you don't like that, then this:
>
> pid = clone(CLONE_FLAGS_TO_SHARE_EVERYTHING)
> if (pid == 0)
> unshare(~flags);
>
>However, if the API you've chosen for unshare() must be kept, then you
>can still have the same checks in clone() and unshare(). Just XOR the
>flags word with bits for polarities that are different between the two
>calls, before doing the checks, and XOR again afterwards to include
>any flags that were forced by the checks.
>
>
>
I am in the process of writing up a more detailed description for this
feature.
Description, which will include requirements, detail design and cost. When I
started, I did try to use as much of the existing code (clone, copy_*) as
possible, but I may have missed things. As I write things down, I will try
and see if I can make flags less confusing.
I am off for the next two weeks with limited email access so don't want to
rearrange stuff now.
>-- Jamie
>
>
>
>
next prev parent reply other threads:[~2005-12-16 4:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-13 22:54 [PATCH -mm 1/9] unshare system call: system call handler function JANAK DESAI
2005-12-15 19:52 ` Eric W. Biederman
2005-12-15 20:38 ` JANAK DESAI
2005-12-15 21:13 ` Eric W. Biederman
2005-12-15 21:32 ` Jamie Lokier
2005-12-15 22:34 ` Eric W. Biederman
2005-12-16 4:36 ` JANAK DESAI
2005-12-16 4:32 ` JANAK DESAI
2005-12-16 10:50 ` Jamie Lokier
2005-12-16 12:46 ` Eric W. Biederman
2005-12-16 17:00 ` Jamie Lokier
2005-12-17 2:23 ` Eric W. Biederman
2005-12-16 14:32 ` Serge E. Hallyn
2005-12-16 12:39 ` Eric W. Biederman
2005-12-15 21:28 ` Jamie Lokier
2005-12-16 4:35 ` JANAK DESAI [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-12-13 13:42 [PATCH -mm 1/9] unshare system call : " JANAK DESAI
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43A243F9.7040600@us.ibm.com \
--to=janak@us.ibm.com \
--cc=akpm@osdl.org \
--cc=chrisw@osdl.org \
--cc=dwmw2@infradead.org \
--cc=ebiederm@xmission.com \
--cc=jamie@shareable.org \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=mingo@elte.hu \
--cc=sds@tycho.nsa.gov \
--cc=serue@us.ibm.com \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox