The realtime preemption endgame [LWN.net]

The realtime preemption endgame

Posted Aug 6, 2009 3:48 UTC (Thu) by tialaramex (subscriber, #21167)
Parent article: The realtime preemption endgame

For the BKL stuff, what is needed to get a BKL-removing patch into a mainline driver?

It seems as though proving thoroughly that the BKL does nothing useful (in some particular driver) is nearly impossible since it interacts so comprehensively with other subsystems, so my first thought was that I should just try removing uses of the BKL from the driver and recompiling. But presumably the LKML would also frown on a patch which says "Drivername: Remove BKL" and offers as justification only the fact that "It works for me".

(Log in to post comments)

The realtime preemption endgame

Posted Aug 6, 2009 8:06 UTC (Thu) by johill (subscriber, #25196) [Link]

> For the BKL stuff, what is needed to get a BKL-removing patch into a mainline driver?

You're expected to carefully review interactions with other subsystems, locking within the driver, identify things relying on the BLK (often it's very little or nothing) and then remove/replace the BLK usage.

The realtime preemption endgame

Posted Aug 6, 2009 10:07 UTC (Thu) by mb (subscriber, #50428) [Link]

> But presumably the LKML would also frown on a patch which says "Drivername: Remove BKL" and offers as justification only the fact that "It works for me".

If you just remove any locking from a driver, it will most likely just work as before. Locking usually is not such a critical thing in a driver that it immediately breaks things.
_But_ it will introduce silent cornercase breakages that you will probably only notice weeks later when some weird coincidence happens.
So you'd better make sure you _do_ understand the locking requirements before removing the BKL from a driver.
Removing the BKL from part of the code requires deep understanding of that code and its interactions with other BKL holders(!). That is the actual problem.