On Fri, Apr 24, 2009 at 11:16:18AM +0200, Fr?d?ric Weisbecker wrote: > I disagree with you. The kill-the-BKL tree does not only aggregate patches > to turn the BKL into more traditional locks. The Bkl has been > converted to a common mutex in > this tree, making it losing its common horrid properties: > > - release/reacquire on schedule > - not preemptable > - can be reacquired recursively by a same task > > Such a basis is very useful because we can easily find these places > which won't support a usual lock conversion without reworking the > locking scheme. > This is a necessary preliminary for the Bkl removal. > All the places which have been designed very tightly with Bkl > properties are rapidly detected > with lockdep in this tree and reworked, still using lockdep, code > reviewing and the help of > this Bkl-to-mutex conversion. > > The work done with this tree can be merged inside and also on the > matching subsytem tree for > each patchset. That's a very sane workflow IMHO. Having a working tree for debugging stuff is fine, but the point is that it should never be pulled into mainline and probably frequently reabsed to avoid cruft. In that case there's really no point in creating branches to share pieces of tree history, just apply the patch locally if you think you want it and merge or rebase once mainline gets the patch. Al frequently rebases the vfs tree, btw - so even if it was a separate branch now there's a fair chance it would end up in mainline with a different commit id. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
