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
--
unsubscribe notice
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/