From: Blaisorblade <blaisorblade@yahoo.it>
To: Jeff Dike <jdike@addtoit.com>
Cc: user-mode-linux-devel@lists.sourceforge.net,
"Eric W. Biederman" <ebiederm@xmission.com>,
linux-kernel@vger.kernel.org, JANAK DESAI <janak@us.ibm.com>
Subject: Re: [uml-devel] Re: [RFC] PATCH 0/4 - Time virtualization
Date: Fri, 28 Apr 2006 22:10:17 +0200 [thread overview]
Message-ID: <200604282210.17956.blaisorblade@yahoo.it> (raw)
In-Reply-To: <20060428151543.GA7397@ccure.user-mode-linux.org>
On Friday 28 April 2006 17:15, Jeff Dike wrote:
> On Fri, Apr 28, 2006 at 03:54:31PM +0200, Blaisorblade wrote:
> > Additionally, if this flag ever goes into clone, it mustn't be named
> > CLONE_TIME, but CLONE_NEWTIME (or CLONE_NEWUTS). And given CLONE_NEWNS,
> > it's IMHO ok to have unshare(CLONE_NEWTIME) to mean "unshare time
> > namespace", even if it's incoherent with unshare(CLONE_FS) - the
> > incoherency already exists with CLONE_NEWNS.
> I wonder if they should be CLONE_* at all.
I've wondered about this too. It makes some sense to renforce the relationship
with clone, but when you read the call to unshare you must do you get
nonsense. Like the above incoherence.
> Given that we are likely
> to run out of free CLONE_* bits, unshare will have to reuse bits that
> don't have anything to do with sharing resources (CSIGNAL,
> CLONE_VFORK, etc), and it doesn't seem that nice to have two different
> CLONE_* flags with the same value, different meaning, only one of
> which can actually be used in clone.
> It seems better to use UNSHARE_*, with the current bits that are
> common to unshare and clone being defined the same, i.e.
> #define UNSHARE_VM CLONE_VM
I indeed agree with this. With
cg log -r v2.6.16-rc1:v2.6.16 kernel/fork.c
We can see the people involved in commits for sys_unshare (there's little
other work in there).
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
next prev parent reply other threads:[~2006-04-28 20:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-13 17:19 [RFC] PATCH 0/4 - Time virtualization Jeff Dike
2006-04-14 0:31 ` john stultz
2006-04-14 1:53 ` [uml-devel] " Jeff Dike
2006-04-14 16:24 ` john stultz
2006-04-19 8:25 ` Eric W. Biederman
2006-04-26 18:01 ` Jeff Dike
2006-04-28 11:33 ` [uml-devel] " Blaisorblade
2006-04-28 11:48 ` Jeff Dike
2006-04-28 12:14 ` Jeff Dike
2006-04-28 13:54 ` Blaisorblade
2006-04-28 15:15 ` Jeff Dike
2006-04-28 20:10 ` Blaisorblade [this message]
2006-04-28 16:18 ` Eric W. Biederman
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=200604282210.17956.blaisorblade@yahoo.it \
--to=blaisorblade@yahoo.it \
--cc=ebiederm@xmission.com \
--cc=janak@us.ibm.com \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/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