> D: Introduces XBUG(comment) and XBUG_ON(comment) macros to PPC and
> D: i386. XBUG prints out module (usually same as objfile without the
> D: .o) and the comment.
> D: It also changes every BUG() in the headers files to XBUG(), so that
> D: the headers don't include absolute filenames, which allows the
> D: kernel compile to use ccache much better.
Just to mention an alternative (I think BUG() is actually designed to be
easy to put in without bothering about writing some explanatory text), I
think the main reason why this is introduced is ccache.
For people who don't know it, ccache(.samba.org) is a program which will
cache the results from previous compiles and just copy the object file
when command line and preprocessed input stayed the same. It immensely
speeds up compiles when you're compiling the same tree twice with only
minor changes, and it's particularly useful for people having multiple
trees around, which only differ in patches they're working on. (As people
who're using bk tend to do, for example)
Well, the last point is actually the issue this is all about. Since
the BUG()'s in the headers will put the full path into the preprocessed
file, ccache will have lots of cache misses, only due to this changed
There's basically two ways around this:
o Remove the __FILE__ in BUG() in headers, which Rusty's patch
o Make sure that the __FILE__ does not contain absolute paths.
I have a patch which does the later, it replaces
(with the right number of '../')
With that patch you'd get
"BUG in ../../include/linux/foo.h:234"
Now, I can't claim that's all that nice, but I think the previous full
path was ugly, too (and we're talking about BUG() here, anyway).
I should mention that there's also another possibility, which actually
looks nicer, but is a bit harder to implement:
Call gcc from $(TOPDIR), so it's always "-Iinclude", and you get
"BUG in include/linux/foo.h:234".
That, BTW, has also the advantage of getting
"BUG in fs/hfs/inode.c:123"
instead of the current
"BUG in inode.c:123"
Actually, I would think the last approach is the cleanest, so if there's
interest in it, I can code it up.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/