[lkml]   [2002]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: BKL removal
>    If nothing else, I hope you will think twice before sending off
> your next BKL removel patch in a subsystem that you haven't fully
> tested or understood. That's the point I keep trying to get across
> here.
>So can you define for me under what conditions the BKL is appropriate
>to use? Removing it from legitimate uses would be bad, of course, but
>part of the problem here is that it's currently used for a variety of
>unrelated purposes.

If the trade-offs weigh in about the same, removing the BKL from
legitimate uses in favor of a different (neither better nor worse)
approach would be more than acceptable, would it not?

Would creating a few new names for lock_kernel() and friends be
acceptable? Just a few macros to give slightly more meaningful names to
each function call for 2.5. Then take lock_kernel() entirely away (the
name, not the function), in 2.7. By 2.9 it should be able to be removed
from nearly all "inappropriate" uses. This seems like it would encourage
more explicit usage of the BKL, while giving maintainers ample time to

Note that I have never added or removed a lock from the kernel. I am
simply thinking aloud; half hoping to be corrected.

--Drew Vogel

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