Hugh's patch looks just dandy to me, even though I
don't understand the problem ;)
> If it wants to be changed, I'd actually personally prefer it to be changed
> to take an explicit string instead of using the filename/linenr at all.
There seem to be two classes of bug report(er)s: the good ones
who do a bit of up-front analysis and the less good ones....
I believe that the BUG() macro should be tuned to the less-good
ones. Generally, these are folk who take their kernels
straight from kernel.org and the line number is not a problem.
People who have applied other patches have the experience and
knowledge to go digging in the source tree and find which
line it was, and to include this in the report.
So.. dunno about others, but I find file-n-line works
not too badly.
> The filename/linenr one has the size problem (those absolute file names
> are _long_), and sucks when you have slight kernel version skew and
> suddenly the information isn't obviously unambiguous at all.
Well given that kbuild-2.5 has a single makefile running
out of $(TOPDIR), it _should_ be chopping the absolute
pathname out of the include path and the .c path:
gcc -I include drivers/net/foo.c
There will be no starting-with-slash __FILE__s in the output of
this command.
> It also sucks for inline functions or other users of BUG that would
> potentially want to have different output.
>
> In short, I suspect it would be nicer with
>
> kernel BUG: release_task(current)
>
> instead of
>
> kernel BUG at /home/torvalds/v2.5/linux/exit.c:59
>
> (the exact point where the BUG happens _is_ given by the EIP, so in that
> sense file and linenr are not actually all that useful. A descriptive
> string would be more readable, and equally useful at pinpointing at a
> source level).
Isn't this the traditional assert(), which includes
that-which-was-asserted in the message?
kernel assertion of "!PageLocked(page)" failed at foo.c:42.
That's easy to do in the context of BUG_ON(), and greatly
increases our chances of pinpointing the failing line...
-
-
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/