* Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > 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 [...] Btw., doing that can (and will) destroy Git history and is pretty explicitly discouraged. > [...] - 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. So did i get you right, you are advocating people to rebase their trees because the VFS tree is rebased often? That's pretty backwards. Ingo -- 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
