[lkml]   [2006]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] unshare: Cleanup up the sys_unshare interface before we are committed.
    Linus Torvalds <> writes:

    > On Fri, 17 Mar 2006, Michael Kerrisk wrote:
    >> > - it's all the same issues that clone() has
    >> At the moment, but possibly not in the future (if one day
    >> usnhare() needs a flag that has no analogue in clone()).
    > I don't believe that.
    > If we have something we might want to unshare, that implies by definition
    > that it was something we wanted to conditionally share in the first place.
    > IOW, it ends up being something that would be a clone() flag.
    > So I really do believe that there is a fundamental 1:1 between the flags.
    > They aren't just "similar". They are very fundamentally about the same
    > thing, and giving two different names to the same thing is CONFUSING.

    The scary thing is that with only 7 things we can share or not,
    and a 32bit field we have only 7 bits left that we can define.
    Last count I think I know of at least that many additional global
    namespaces in the kernel.

    On the confusing side. Unshare largely because it doesn't default to
    unsharing all of the thread state. Has the weird issue that unshare
    will automatically add bits you didn't ask for (so it can satisfy your
    request) and unsharing more than you requested. Clone when presented
    with the same situation returns an error.

    So even while the resources are the same the interaction of the
    bits really is quite different between the two calls.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-03-17 17:09    [W:0.026 / U:0.472 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site