Re: -mm -> 2.6.13 merge status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 23 2005, Andrew Morton wrote:
> Jeff Mahoney <[email protected]> wrote:
> >
> > >>+	assert("nikita-955", pool != NULL);
> >  > 
> >  > These assertion codes are meaningless to the rest of us so please drop
> >  > them.
> > 
> >  As someone who spends time debugging reiser3 issues, I've grown
> >  accustomed to the named assertions. They make discussing a particular
> >  assertion much more natural in conversation than file:line.
> 
> __FUNCTION__?

Doesn't help a lot. I've also been annoyed several times in the past
when having to lookup a BUG() for a kernel source I don't exactly have
at hand right then and there. If you have constructs ala

function()
{
        if (cond_a)
                BUG();
        if (cond_b)
                BUG();
        if (cond_c)
                BUG();

        do_stuff...
}

then it's impossible to know which one it is without the identical
source at hand.

That said, I don't like the reiser name-number style. If you must do
something like this, mark responsibility by using a named identifier
covering the layer in question instead.

        assert("trace_hash-89", is_hashed(foo) != 0);

or whatever.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux