On Thu, Aug 28, 2008 at 9:05 PM, Alexey Dobriyan  wrote:

quoted text
> On Thu, Aug 28, 2008 at 08:46:43PM +0200, Vegard Nossum wrote:

>> On Thu, Aug 28, 2008 at 8:40 PM, Alexey Dobriyan  wrote:

>> > On Thu, Aug 28, 2008 at 08:32:23PM +0200, Vegard Nossum wrote:

>> >> How do you feel about this patch? It's all about making kmemcheck more

>> >> useful... and not much else. Does it have any chance of entering the

>> >> kernel along with kmemcheck (when/if that happens)?

>> >

>> > DEFINE_BITFIELD is horrible.

>> >

>> >> @@ -285,11 +286,12 @@ struct sk_buff {

>> >>               };

>> >>       };

>> >>       __u32                   priority;

>> >> -     __u8                    local_df:1,

>> >> +     DEFINE_BITFIELD(__u8,   flags1,

>> >> +                             local_df:1,

[...]
>> Would it help (to make this less

quoted text
>> horrible) to omit the type declaration and have just the bitfield

>> members as arguments to the macro?

>

> Or you can parse instruction stream a bit more.

I think we have different opinions of what exactly constitutes "horrible" :-P
Your suggestion would have made sense if I was a company of 10

developers who could import all of valgrind source code (including

opcode decoder and instruction emulator) into the kernel. But I only

writing kmemcheck in my free time, so this will never happen. Or.. at

least I will not do it. Of course, kmemcheck, valgrind/memcheck, and

indeed the kernel itself are all open source, so anybody could do it.

And if you want to submit patches yourself, the effort will be welcome

:-)
In the mean-time, I am looking for an acceptable solution. Other

debugging features use helper annotations too. But I am pretty sure

that the immediate solution will not include parsing the instruction

stream a bit more.
Vegard
--

"The animistic metaphor of the bug that maliciously sneaked in while

the programmer was not looking is intellectually dishonest as it

disguises that the error is the programmer's own creation."

	-- E. W. Dijkstra, EWD1036

--

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