On Fri, 23 Nov 2001, Rick Lindsley wrote:
> Christoph Hellwig <hch@ns.caldera.de> said:
>
> Nope, it's fine to remove it. Input is racy all over the place and the list
> are modified somewhere else without any locking anyways.
>
> Horst von Brand <vonbrand@inf.utfsm.cl> then said:
>
> "It is broken anyway, breaking it some more makes no difference"!?
>
> No, it is more a matter of "it is not helping at all, so removing it
> makes no difference in behavior." Removing it does, however, help
> clean up the code and remove unnecessary instances of the BKL from the
> kernel code.
>
> If you check the web page at
> http://lse.sourceforge.net/lockhier/patches.html, you'll find
> additional information on why this patch was produced. The most common
> "no-op" was that (BKL) locking was done during release but not during
> open. In some cases, there truly are things to guard. In some cases,
> there really isn't. In all cases, nothing was really being correctly
> guarded.
While this is doubtlessly true, please don't do things like removing the
lock from interfaces like the call to open() in the input subsystem.
People may depend on the lock being held there. Having open() under BKL
simplifies writing USB device drivers.
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 : Fri Nov 23 2001 - 21:00:33 EST