lkml.org 
[lkml]   [2009]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][v8][PATCH 9/10]: Define clone3() syscall
    Michael Kerrisk [mtk.manpages@googlemail.com] wrote:
    | Sukadev,
    |
    | On Wed, Oct 21, 2009 at 9:44 PM, Sukadev Bhattiprolu
    | <sukadev@linux.vnet.ibm.com> wrote:
    | > H. Peter Anvin [hpa@zytor.com] wrote:
    | >> On 10/21/2009 01:26 PM, Michael Kerrisk wrote:
    | >>>
    | >>> My question here is: what does "3" actually mean? In general, system
    | >>> calls have not followed any convention of numbering to indicate
    | >>> successive versions -- clone2() being the one possible exception that
    | >>> I know of.
    | >>>
    | >>
    | >> "3" is number of arguments.
    | >
    | > To me, it is a version number.
    |
    | See my precending mail. Isn't the number of arguments "2".

    Well it was 2 at one point, but I have posted a new version of
    just that one patch - please see http://lkml.org/lkml/2009/10/16/3
    for comments.

    I am working on some updates and will post a new patchset - it
    will have 3 parameters to clone3() as shown in the above mail.

    |
    | > mmap() and mmap2() both have 6 parameters.
    | >
    | > Besides if wait4() were born before wait3(), would it still be wait4() :-)
    | > But I see that it is hard to get one-convention-that-fits-all.
    |
    | Yes -- that's exactly right.
    |
    | >> It's better than "extended" or something
    | >> like that simply because "extended" just means "more than", and a number
    | >> at least tells you *how much more than*.
    | >
    | > And extended assumes we wont extend again.
    |
    | Well, if we do things right in this design, we may not need to ever
    | extend (by creating a new syscall) again. That's why I mentioned the
    | "flags" argument idea. Did you give this some thought?

    Yes, we have done the best we can to avoid extending clone() again
    anytime soon (some reserved bytes and clone_args_size field). Would
    we still need the flags parameter ? Again its in the new patch
    that I pointed to above.

    |
    | > An informal poll of reviewers has clone3() with a slight advantage :-)
    | >
    | >        clone_extended() camp: Serge Hallyn, Kerrisk, Louis Rilling,
    | >        clone3(): Sukadev, H. Peter Anvin, Oren, Matt Helsley.
    | >
    | > I like clone3() but am not insisting on it. I just want a name...
    |
    | And I'm not really insisting on a change. As you rightly point out,
    | there is much inconsistency in the naming conventions that have been
    | used over the years.
    |
    | But, because there has been no consistency in the use of numbers, and
    | because the number of arguments that are presented in a glibc
    | interface may differ from the number of arguments in an underlying
    | syscall (several precedents: signalfd4(), pselect(), ppoll()), I'm
    | inclined to think that clonex() or clone_ext() is slighly better than
    | clone3(). But, certainly, my arguments are not compelling.
    --
    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/

    \
     
     \ /
      Last update: 2009-10-22 20:11    [W:0.025 / U:31.084 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site