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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]