[lkml]   [2002]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] ext2_fill_super breakage

    On Thu, 28 Mar 2002, Andrew Morton wrote:

    > > For one thing, the latter is hell on any search.
    > If the usage of the type is hard to search for then
    > then wrong identifier was chosen.


    Search for ext2_sb_info will give you all places that refer to it.
    Including a buttload of
    struct ext2_sb_info *p;

    Now, search for ext2_sb_info[ ]*[^ *] is much more interesting.
    With explicit sizeof it is guaranteed to give you all places where
    such beast is allocated or subjected to memset, etc.

    In this case it's not too interesting. But try it for struct super_block
    or struct dentry or struct buffer_head, etc. - anything that is widely

    > (and I think this is something on which you and I somewhat
    > differ) code should be written for the convenience of others,
    > not the original author.

    Ahem. Right now I'm digging through the <expletives> known as lvm.c
    trying to fix the use of kdev_t in ioctls. Believe me, I'm _not_
    the original author. "Where the heck do they initialize <field>" is
    the question I've to deal with all the time and I'd rather have it
    (along with "where the heck do they allocate and free their monsters")
    as greppable as possible.

    BTW, I _really_ wonder who had audited lvm.c for inclusion - quite a
    few places in there pull such lovely stunts as, say it, use of strcmp()
    on a user-supplied array of characters. Whaddya mean, "what if there's
    no NUL"? Sigh...

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:25    [W:0.025 / U:246.064 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site