On Thursday 09 October 2008 07:55:58 Christoph Hellwig wrote: > On Thu, Oct 09, 2008 at 04:20:49AM +0200, Christian Parpart wrote: > > Hi, > > > > this now makes use of autoconf/automake/libtool suite, > > thus, enabling a wider range of platforms etc. > > Although, I've split up the build into tools, lib, and tests, > > making it possible for 3rd-parties to link against libbtrfs now. > > I don't think allowing 3rd parties to link against it is a good idea. > It's basically the kernel code with a few wrappers around it, and will > change a lot over time. I already noticed that, and this is another thing: Why is the kernel module and the userland duplicating so much code? As of ZFS, they've written a set of libraries (libzfs, libzpool, kernel compat libs, ...) that are shared between userland and kernel, thus, making porting to other platforms lots of easier. If btrfs would do the same aproach, it could also benifit from a fuse frontend (aside the kernel module) to be used for debugging purposes, think of gdb, valgrind (or cachegrind) to mention the most interesting ones. I talked to yangzheng about this, and he said that this just seems to lag a volunteer to do, however, *after* the disk format is completed. Regards, Christian Parpart. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
