Cc: Ingo Molnar <mingo@...>, Andrew Morton <akpm@...>, Peter Zijlstra <a.p.zijlstra@...>, Thomas Gleixner <tglx@...>, Alan Cox <alan@...>, Alexander Viro <viro@...>, <linux-kernel@...>
Btw, Jonathan, would you be willing to maintain some kind of tree of these
BKL removal patches?
This is different from the work Ingo is doing in the sense that these
things should be (a) safe and reasonably obvious and thus (b) presumably
ready to be merged in the next merge window. Ingo's BKL debugging tree is
likely a good thing to use to find places that need work, but actually
removing the BKL from some subsystem is a different issue.
(And when I say "safe and reasonably obvious" I obviously don't mean that
there can't be bugs. Mistakes happen, and some BKL use might be overly
subtle like the issue that Alan pointed out with an empty ->open routine
almost accidentally serializing with initialization, but that's why I'd
not merge these things after -rc2 anyway, but in the next merge window).
Because if you're willing to maintain a BKL-cleanup tree that gets merged
into linux-next etc, I'd submit my VFAT/MSDOS BKL removal patch to you.
The reason I did that one was that Thomas actually reported that to be a
major source of latency problems on one of his embedded systems (80ms
latency!), so it would be nice to have that patch in some place where it
might get tested.
Linus
--
