[..]
> Excuse me, but please do NOT compare coding style with using the BKL! I
> can use the BKL in my code just fine, and it does not impare your
> ability to use, modify, or understand my code. As long as I comment why
> I am using the BKL.
That should be something the maintainers enforce.
[..]
> > 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.
>
> Also, stay away from instances of it's use WHERE IT DOES NOT MATTER for
> performance. If I grab the BKL on insertion or removal of a USB device,
> who cares? I know you are trying to remove it entirely out of the
> kernel, but please focus on places where it actually helps, and leave
> the other instances alone.
If you really want to make maximum impact, do tests. Very few people can measure
lock contention on a 4-CPU system. And please rest assured that nobody wants to
be maintainer of the subsystem that ruins scalability.
And if you see a use of the BKL you don't understand ask first, or send a patch
to the subsystem's mailing list, not lkml. People will look at BKL usage if you ask.
In fact such a look might even uncover bugs as in case of USB.
Regards
Oliver
-
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