[patch 0/17] Series to introduce WARN()... a WARN_ON() variant that takes printk arguments - Kernel

This is a discussion on [patch 0/17] Series to introduce WARN()... a WARN_ON() variant that takes printk arguments - Kernel ; On Fri, 11 Jul 2008 16:02:13 -0700 Andrew Morton wrote: > On Fri, 11 Jul 2008 15:51:05 -0700 Arjan van de Ven > wrote: > > > On Fri, 11 Jul 2008 15:11:10 -0700 > > Andrew Morton wrote: > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 22 of 22

Thread: [patch 0/17] Series to introduce WARN()... a WARN_ON() variant that takes printk arguments

  1. Re: [patch 13/17] Use WARN() in drivers/base/

    On Fri, 11 Jul 2008 16:02:13 -0700
    Andrew Morton wrote:

    > On Fri, 11 Jul 2008 15:51:05 -0700 Arjan van de Ven
    > wrote:
    >
    > > On Fri, 11 Jul 2008 15:11:10 -0700
    > > Andrew Morton wrote:
    > >
    > > >
    > > > I don't suppose there's any way of tricking the preprocessor into
    > > > supporting
    > > >
    > > > WARN_ON(foo == 42);
    > > >
    > > > as well as
    > > >
    > > > WARN_ON(foo == 42, "bite me!");
    > > >

    > >
    > > after reading preprocessor docs from gcc and trying some things:
    > > We can do this. It comes at a price: the price is a blank line in
    > > the WARN trace for the "no printk comments" case, and we lose the
    > > ability to override the printk level. (which you can argue is a
    > > feature by just setting it to KERN_WARNING).
    > >
    > > (and some interesting but otherwise non-harmful preprocessor stuff
    > > in headers)

    >
    > the blank line: might be avoidable by doing some extra work at runtime
    > to recognise its presence?


    probably (but vararg stuff is weird)

    >
    > overriding facility level: doesn't sound very useful, as WARN()'s
    > stack-trace's facility level is not controllable.


    ok

    >
    > > Is this is price worth paying to not have a second macro?

    >
    > Dunno, how ugly is the patch?


    it's not too bad I'll turn the userland experiment into a kernel
    patch tomorrow or so

    >
    > It would be rather nice to not go and fatten the interface. Would
    > there be additional text or data size costs?


    there will be a few bytes of text in the out of line implementation;
    I'm not too worried about that.
    There shouldn't be a per-instance overhead

    --
    If you want to reach me at my work email, use arjan@linux.intel.com
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    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/

  2. Re: [patch 13/17] Use WARN() in drivers/base/


    > #define WARN_ON(test, fmt...) \
    > do { \
    > if (test) { \
    > warn_on_slowpath(cnt(fmt) , ## fmt); \
    > printf("WARN\n"); \
    > } \
    > } while (0)


    That doesn't play well with the bugtrap stuff, obviously. This one is a
    bit better, but still has more overhead than the bugtrap stuff, but
    avoids the overhead in the no-argument case.


    #include
    #include

    #define unlikely(x) (x)

    #define hasargs(...) _hasargs( , ## __VA_ARGS__)
    #define _hasargs(...) __hasargs(__VA_ARGS__,1,1,1,1,1,1,1,1,1,1,1,1,1,1, 1,1,1,1,1,0)
    #define __hasargs(x0,x1,x2,x3,x4,x5,x6,x7,x8,x9,x10,x11,x1 2,x13,x14,x15,x16,x17,x18,x19,n,ys...) n

    static void warn_slowpath(int count, ...)
    {
    va_list args;
    char *fmt;

    printf("WARNING: <<\n");

    if (count) {
    va_start(args, count);
    fmt = va_arg(args, char *);
    vprintf(fmt, args);
    va_end(args);
    }
    printf(">>\n");
    }

    /*
    * This is the original arch WARN_ON that just emits
    * a trap instruction and a bugtrap section entry for
    * example on powerpc.
    *
    * Obviously this isn't, but it could be.
    */
    #define BUGTRAP_WARN_ON(test) ({ \
    if (unlikely(test)) \
    printf("WARNING: %s\n", #test); \
    unlikely(test); \
    })

    /*
    * This is a WARN_ON for some other architectures that don't
    * use the bugtrap section, it calls the slowpath function
    * which leads to more code size. But when you've added
    * parameters to your WARN_ON those need to be calculated
    * as well so you've already increased code size.
    */
    #define OUT_OF_LINE_WARN_ON(test, fmt...) ({ \
    if (unlikely(test)) \
    warn_slowpath(hasargs(fmt) , ## fmt); \
    unlikely(test); \
    })

    /*
    * This new version determines whether to do a bugtrap
    * entry or not depending on whether there were any extra
    * arguments given.
    */
    #define CONFIG_BUG_EXTRA_VERBOSE
    #ifdef CONFIG_BUG_EXTRA_VERBOSE
    #define WARN_ON(test, fmt...) ({ \
    if (!hasargs(fmt)) \
    BUGTRAP_WARN_ON(test); \
    else \
    OUT_OF_LINE_WARN_ON(test , ## fmt); \
    })
    #else
    #define WARN_ON(test, fmt...) BUGTRAP_WARN_ON(test)
    #endif

    int main(void)
    {
    WARN_ON(1);
    WARN_ON(2, "asdf %d %d\n", 7, 8);
    WARN_ON(3, "asdf\n");

    return 0;
    }


    --
    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/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2