[lkml]   [2002]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: BKL removal

On Tue, 9 Jul 2002, Dave Hansen wrote:

> I have the feeling that the filesystems' use of lots of function
> pointers will add a large amount of complexity to whatever programming
> any checker would require. Bill Irwin and I were discussing it and we
> have ways of getting around most of them, but there are _lots_ of
> special cases.

The real complexity is _not_ on compiler level. Checker manages that
quite fine. The problem is in the coverage - making sure that code
gets to compiler is much, much more painful.

> > Normally it's not that bad, but "can this function block?" is very nasty
> > in that respect - changes of configuration can and do affect that in
> > non-trivial ways.
> I also wonder how it handles things like kmalloc(), which can block
> depending on arguments.

Not a big deal - checker can be taught how kmalloc() works (normally we
either pass it explict constant or an argument of calling function -
without any changes).

Again, the real mess is due to the way we use cpp. It would be wonderful if
we had 4-6 options really affecting stuff (changing structure sizes, etc.)
and everything else would be handled either on compiler (
and let compiler eliminate dead branches) or on the linker (
obj-$(CONFIG_BAR) += bar.o
) level. Then the life would be _way_ easier and we would really have
a chance to do a meaningful coverage.

As it is, we have way too many ifdefs to hope that any automated tool
would be able to cope with the damn thing. It used to be worse -
these days several really nasty piles of ifdefs are gone. However,
we still have quite a few remaining.

Quick-and-dirty search shows ~1.2e4 ifdefs on CONFIG_... in the tree.
Most of them - patently ridiculous (random example: fs/ncpfs/symlink.c
<usual comments in the beginning>

#include <linux/config.h>

<lots of stuff>

/* ----- EOF ----- */

which should be

ncpfs-objs += symlink.o

in Makefile and none of the crap in symlink.c).

However, there's really bad stuff and it also has to be dealt with...

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