[lkml]   [2009]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH -v7][RFC]: mutex: implement adaptive spinning

    On Fri, 9 Jan 2009, Harvey Harrison wrote:

    > On Sat, 2009-01-10 at 02:01 +0100, Ingo Molnar wrote:
    > > - Headers could probably go back to 'extern inline' again. At not small
    > > expense - we just finished moving to 'static inline'. We'd need to
    > > guarantee a library instantiation for every header include file - this
    > > is an additional mechanism with additional introduction complexities
    > > and an ongoing maintenance cost.
    > Puzzled? What benefit is there to going back to extern inline in headers?

    There's none. In fact, it's wrong, unless you _also_ have an extern
    definition (according to the "new" gcc rules as of back in the days).

    Of course, as long as "inline" really means _always_ inline, it won't
    matter. So in that sense Ingo is right - we _could_. Which has no bearing
    on whether we _should_, of course.

    In fact, the whole mess with "extern inline" is a perfect example of why a
    inlining hit should be called "may_inline" or "inline_hint" or something
    like that.

    Because then it actually makes sense to have "extern may_inline" with one
    definition, and another definition for the non-inline version. And it's
    very clear what the deal is about, and why we literally have two versions
    of the same function.

    But again, that's very much not a "let's use 'extern' instead of
    'static'". It's a totally different issue.


    [ A third reason to use "extern inline" is actually a really evil one: we
    could do it for our unrelated issue with system call definitions on
    architectures that require the caller to sign-extend the arguments.

    Since we don't control the callers of system calls, we can't do that,
    and architectures like s390 actually have potential security holes due
    to callers that don't "follow the rules". So there are different needs
    for trusted - in-kernel - system call users that we know do the sign
    extension correctly, and untrusted - user-mode callers that just call
    through the system call function table.

    What we _could_ do is for the wrappers to use

    extern inline int sys_open(const char *pathname, int flags, mode_t mode)
    return SYS_open(pathname, mode);

    which gives the C callers the right interface without any unnecessary
    wrapping, and then

    long WRAP_open(const char *pathname, long flags, long mode)
    return SYS_open(pathname, flags, mode);
    asm ("\t.globl sys_alias\n\t.set WRAP_open");

    which is the one that gets linked from any asm code. So now asm code
    and C code gets two different functions, even though they use the same
    system call name - one with inline expansion, one with linker games.

    Whee. The games we can play (and the odd reasons we must play them). ]

     \ /
      Last update: 2009-01-10 02:35    [W:0.023 / U:19.876 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site