Re: [uml-devel] Re: [RFC] PATCH 0/4 - Time virtualization

[Blaisorblade <blaisorblade@yahoo.it>]

On Friday 28 April 2006 13:48, Jeff Dike wrote:
> On Fri, Apr 28, 2006 at 01:33:40PM +0200, Blaisorblade wrote:
> > > So, maybe it belongs in clone as a "backwards" flag similar to
> > > CLONE_NEWNS.

> > I must note that currently every (?) flag allowed for unshare is also
> > allowed for clone, so you need to do that anyway.

> Currently.  We are running out of CLONE_ bits - in mainline, there are
> three left, and two of them are likely to be used by CLONE_TIME and
> CLONE_UTSNAME (or whatever that turns out to be called).

> And why should there be any overlap between clone flags and unshare
> flags?  Isn't
> 	clone(CLONE_TIME);
> the same as
> 	clone();
> 	unshare(CLONE_TIME);
> ?

Now that unshare() exists, you're right, the current situation is just due to 
unshare() being an afterthought; the second form (clone() + unshare()) is 
actually more similar to the classical fork() API conceptually (i.e. you 
don't need a call with thousands of parameters to create a process, you can 
specify everything later).

So we get back to Eric's objection (which I haven't understood but that's my 
problem).

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