On Mon, Nov 15, 2010 at 04:32:30PM +1100, Nick Piggin wrote: > I mean, your dentry lru modification patch really didn't need to be > pulled ahead of my other patches and and subtly changed. That just > scatters wreckage throughout my patchset, which goes beyond just > merging things up but also all the stress testing and verification I've > done goes out the window too. There's a lot more dcache cleanups that need to go in before we can do the lock splitting in a sensible way. I have started doing that a couple of weeks ago while you were away. I've been keeping this back in the hope that we could the mud fight and get back to the table working together. Any good way to encourage you to stick to the techical feedback instead of two or three flames in reply to any disagreement by others? Also I'd be very happy you could stop sending me personal accusations of a troll. > Yes, I may not have the thing structured *exactly* as you want it, but > really, unless it is a real problem, just look at the big picture a bit > more. In VFS land we've done pretty well with doing cleanups before locking or algorithm changes to make them smaller and better to audit. It's not just my opinion, ask Al for his even more fine grained split up request for the inode_lock splitup. I think splitting things into these small blocks and moving the cleanup bits to the beginning has helped that code a lot. We found a couple of bugs, both in the initial patches and the later version, and the final patches are very easy to understand and verify. Yes, it is a lot more work, but the result does pay off. -- 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
