Re: BKL removal

[Oliver Neukum <oliver@neukum.name>]

[..]
> 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