[lkml]   [2002]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: BKL removal
    Wait!  You're still not getting it.  I'm not against removing the
BKL. I'm not saying we should add it to more places. What I am
complaining about (and I'm not the only one) is the method that
people who are trying to remove the BKL from various kernel
subsystems are using.

[ ... ]

So please, no more "hit and run" BKL patches that break things.
Please come offering to help, with detailed reasons why BKL usage
is wrong in the specific portions of the code, and how possibly it
might be cleaned up, with patches that have _actually been

I understand. But there's a bit of a problem here. We don't have
every device available to us that uses the BKL. The maintainers, I
presume, do. While we can inspect to our little hearts' content, and
code up "obviously" correct patches, nothing really tests it like,
well, testing it. In the past, in writing to maintainers, we have
sometimes found that a) they ignore email that does not include actual
patches, or b) they don't know themselves if it is safe, and are afraid
or unwilling to try it themselves. So there's no means to discuss
changes, no means to test them, and (some) maintainers then refuse to
apply ANY changes.

(Others take the opposite approach, and apply anything that looks like
a patch -- ALSO probably not the desired result :)

This is not to say that you, as a maintainer, behave this way. But we
HAVE observed this behavior in our efforts. What is the proper
response when a maintainer won't apply a change, won't help test it,
and won't even help derive a correct one? About all that's left at
that point, it seems, is to provide a patch, appeal to the community at
large, and ask them to try it or comment upon it.

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