All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Dike <jdike@addtoit.com>
To: Blaisorblade <blaisorblade@yahoo.it>
Cc: user-mode-linux-devel@lists.sourceforge.net,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [uml-devel] Re: [RFC] PATCH 0/4 - Time virtualization
Date: Fri, 28 Apr 2006 11:15:43 -0400	[thread overview]
Message-ID: <20060428151543.GA7397@ccure.user-mode-linux.org> (raw)
In-Reply-To: <200604281554.32665.blaisorblade@yahoo.it>

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.  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

				Jeff


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

WARNING: multiple messages have this Message-ID (diff)
From: Jeff Dike <jdike@addtoit.com>
To: Blaisorblade <blaisorblade@yahoo.it>
Cc: user-mode-linux-devel@lists.sourceforge.net,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [uml-devel] Re: [RFC] PATCH 0/4 - Time virtualization
Date: Fri, 28 Apr 2006 11:15:43 -0400	[thread overview]
Message-ID: <20060428151543.GA7397@ccure.user-mode-linux.org> (raw)
In-Reply-To: <200604281554.32665.blaisorblade@yahoo.it>

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.  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

				Jeff

  reply	other threads:[~2006-04-28 16:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-13 17:19 [uml-devel] [RFC] PATCH 0/4 - Time virtualization Jeff Dike
2006-04-13 17:19 ` Jeff Dike
2006-04-14  0:31 ` [uml-devel] " john stultz
2006-04-14  0:31   ` john stultz
2006-04-14  1:53   ` [uml-devel] " Jeff Dike
2006-04-14  1:53     ` Jeff Dike
2006-04-14 16:24     ` john stultz
2006-04-14 16:24       ` john stultz
2006-04-19  8:25 ` Eric W. Biederman
2006-04-19  8:25   ` Eric W. Biederman
2006-04-26 18:01   ` [uml-devel] " Jeff Dike
2006-04-26 18:01     ` Jeff Dike
2006-04-28 11:33     ` [uml-devel] " Blaisorblade
2006-04-28 11:33       ` Blaisorblade
2006-04-28 11:48       ` Jeff Dike
2006-04-28 11:48         ` Jeff Dike
2006-04-28 12:14         ` Jeff Dike
2006-04-28 12:14           ` Jeff Dike
2006-04-28 13:54         ` Blaisorblade
2006-04-28 13:54           ` Blaisorblade
2006-04-28 15:15           ` Jeff Dike [this message]
2006-04-28 15:15             ` Jeff Dike
2006-04-28 20:10             ` Blaisorblade
2006-04-28 20:10               ` Blaisorblade
2006-04-28 16:18           ` Eric W. Biederman
2006-04-28 16:18             ` Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2006-04-14 15:39 Brock, Anthony - NET
2006-04-14 15:33 ` Jeff Dike

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=20060428151543.GA7397@ccure.user-mode-linux.org \
    --to=jdike@addtoit.com \
    --cc=blaisorblade@yahoo.it \
    --cc=ebiederm@xmission.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.