On Sun, Jul 07, 2002 at 02:35:31PM -0700, Dave Hansen wrote:
>
> "As long as I comment [and understand] why I am using the BKL."
> would be a bit more accurate. How many places in the kernel have you
> seen comments about what the BKL is actually doing? Could you point
> me to some of your comments where _you_ are using the BKL? Once you
> fully understand why it is there, the extra step of removal is usually
> very small.
I have never written any kernel code that added usages of the BKL. The
fact that I am now maintaining code that uses it should not be confused
with this. Yes, some of my filesystems (pcihpfs and usbfs) now use it,
but that was due to other people pushing it down, out of the VFS.
> >>A lock with a single purpose, guarding relatively small amounts of
> >>data is much easier to understand than one such as the BKL. Would you
> >>want a simple VM operation to take 1 second as the TTY layer and ext3
> >>take their sweet time with the BKL?
> >
> >If ext3 is spinning on the BKL, then try to fix that, as it seems like a
> >worthwhile task (like the ext2 changes proved.) If you want to remove
> >the BKL from the tty layer, be my guest, that will involve rewriting
> >that whole subsystem :)
>
> All that I'm saying is that there can be unintended consequences. By
> having it in your code, you open the possibility of these strange
> interactions and a drop in _your_ code's reliability.
Yes, and there can be unintended conequences for just blindly removing
the BKL as your input layer patch proved. The input layer was using the
BKL in a reliable manner, it just wasn't documented. And by using the
BKL in my code, it does not decrease reliability in any way (just might
slow it down under some system loads, but it still works properly.)
> I'm staying well away from the TTY layer, it is just a well known
> example.
Ah, so it's easier to try to pick on subsystems that don't matter like
USB and driverfs? :)
> >>I would mind the BKL a lot less if it was as well understood
> >>everywhere as it is in VFS. The funny part is that a lock like the
> >>BKL would not last very long if it were well understood or documented
> >>everywhere it was used.
> >
> >I would mind it a whole lot less if when you try to remove the BKL, you
> >do it correctly. So far it seems like you enjoy doing "hit and run"
> >patches, without even fully understanding or testing your patches out
> >(the driverfs and input layer patches are proof of that.) This does
> >nothing but aggravate the developers who have to go clean up after you.
>
> Like it or not, the only way to get maintainers to pay any attention
> at all is to give them code. Is there more likely to be progress if I
> just say, "Hey Greg, why don't you take the BKL out of USB", or if I
> send you a crappy patch which has the beginning of a valid approach?
> Code gets people thinking.
Either way, you get my same response, "Why?" Again, as someone stated,
where in the USB code is the BKL used that affects performance in any
real life situations?
And yes, sending crappy patches does get people jumping, but don't rely
on that being a good method of doing development. People only fall for
that one so many times.
greg k-h
-
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 : Sun Jul 07 2002 - 22:00:18 EST