Messages in this thread | | | From | Blaisorblade <> | Subject | Re: [uml-devel] Re: [RFC] PATCH 0/4 - Time virtualization | Date | Fri, 28 Apr 2006 15:54:31 +0200 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |