lkml.org 
[lkml]   [2000]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [idea] request_module(const char *fmt, ...);
    Now I found a reason why request_module() can *NOT* be a macro. Ever.
    Because it wouldn't work for the calls like

    (void) request_module("ide-blabla");

    or

    if (request_module("misc-blabla") == 0)

    or some others you can easily imagine. It *worked* before only because all
    the calls to request_module() were either surrounded by CONFIG_KMOD or
    were in the form of a very simple:

    request_module(modname);

    So, having it as macro or not is not a matter of taste. Having it as a
    macro is *wrong*. It is inconsistent, because it assumes the callers
    surround their code with CONFIG_KMOD, but some (e.g. telephony) don't but
    just use it in a "valid" way.

    This time I cc'd Linus because this finding puts the last nail on the
    coffin of the "we want macro and not a function" approach and therefore
    proves the validity of my implementation (the patch I sent earlier):

    http://www.ocston.org/~tigran/patches/kmod-2.3.40-p1.patch

    Regards,
    ------
    Tigran A. Aivazian | http://www.sco.com
    Escalations Research Group | tel: +44-(0)1923-813796
    Santa Cruz Operation Ltd | http://www.ocston.org/~tigran

    On Wed, 12 Jan 2000, James Manning wrote:

    > [ Wednesday, January 12, 2000 ] Tigran Aivazian wrote:
    > > In cases where it adds substantial overhead
    > > of re-walking through the entire list (e.g. get_fs_type which walks
    > > through file_systems) the caller should (and does) check the return from
    > > request_module() and only does the extra work if it is == 0.
    >
    > But the beauty of the macro method is that you have a much (relatively)
    > smaller kernel as your preprocessor reduces the request_module to -EINVAL
    > at compile-time and you get to let gcc optimize away (dump dead code :)
    > the entire chunk of code... you've saved a branch, cache efficiency, etc..
    >
    > James
    > --
    > Miscellaneous Engineer --- IBM Netfinity Performance Development
    >




    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:0.023 / U:382.804 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site