[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.065 / U:52.916 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site