Re: [RFC PATCH] explicitly mark recursion count
From: Davide Libenzi
Date: Wed Jun 02 2004 - 18:23:35 EST
On Wed, 2 Jun 2004, [iso-8859-1] Jörn Engel wrote:
> Yeah, I know about the problems to generate a complete call graph.
> With function pointers, it is plain impossible to get it right in the
> most general case.
> Note the "in the most general case" part. You can get things right if
> you make some assumptions and those assumptions are actually valid.
> In my case the assumptions are:
> 1. all relevant function pointers are stuffed into some struct and
> 2. no casts are used to disguise function pointer as something else.
> If you stick with those rules, the resulting code is quite sane, which
> is much more important than any tools being usable. If the kernel
> doesn't stick to those rules for a good reason, I'd like to know about
> it, so I can adjust my tool. And if the kernel doesn't stick to those
> rules for no good reason, the code if broken and needs to be fixed.
> Is this sane?
Think at file_operations as very simple example, and try to find out what
is actually called when somewhere the code does f_op->*(). How would you
build the graph down there. You'd have to record all the functions that
have been assigned to such method throughout the code, and nest *all*
their graph in place. And this will eventually trigger false positives.
Similar thing with functions that accepts callbacks, either directly or
inside structures. And this doesn't even start to take aliasing into
account. Hunting stack hungry functions is very good, and having a tool
that is maybe 60% precise in detecting loops is fine too. But requiring
metadata to be maintained to support such tool is IMO wrong.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/