> 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
comply.
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:14 EST