On Sat, Jan 03, 2009 at 02:50:34PM -0500, Christoph Hellwig wrote: > On Sat, Jan 03, 2009 at 12:17:06PM -0700, Matthew Wilcox wrote: > > It's no worse than XFS (which still has its own implementation of > > 'synchronisation variables', > > Which are a trivial wrapper around wait queues. I have patches to kill > them, but I'm not entirely sure it's worth it I'm not sure it's worth it either. > > a (very thin) wrapper around mutexes, > > nope. It's down to: typedef struct mutex mutex_t; but it's still there. > > a > > (thin) wrapper around rwsems, > > Which are needed so we can have asserts about the lock state, which > generic rwsems still don't have. At some pointer Peter looked into > it, and once we have that we can kill the wrapper. Good to know. Rather like btrfs's wrappers around mutexes then ... > > > - compat.h needs to go > > > > Later. It's still there for XFS. > > ? XFS still has 'fs/xfs/linux-2.6'. It's a little bigger than compat.h, for sure, and doesn't contain code for supporting different Linux versions, sure. But it's still a compat layer. > > > - there should be manpages for all the ioctls and other interfaces. > > > > I wonder if Michael Kerrisk has time to help with that. Cc'd. > > Actually a lot of the ioctl API don't just need documentation but > a complete redo. That's true at least for the physical device > management and subvolume / snaphot ones. That's a more important critique than Andi's. Let's take care of that. > From painfull experience with a lot of things, including a filesystem > you keep on mentioning it's clear that once stuff is upstream there > is very little to no incentive to fix these things up. I don't think that's as true of btrfs as it was of XFS -- for example, Chris has no incentive to keep compatibility with IRIX, or continue to support CXFS. I don't think 'getting included in kernel' is Chris' goal, so much as it is a step towards making btrfs better. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- 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
