Hi David, I really have concerns about the libification, in particular this commit: 6fc8b21 btrfs-progs: libify some parts of btrfs-progs The relevant snippets that concern me below: +libbtrfs_headers = send-stream.h send-utils.h send.h rbtree.h btrfs-list.h \ + crc32c.h list.h kerncompat.h radix-tree.h extent-cache.h \ + extent_io.h ioctl.h ctree.h ... +headers = $(libbtrfs_headers) ... + $(INSTALL) -m644 $(headers) $(DESTDIR)$(incdir) I really don't think that all those headers should be exposed to the userspace. I think, to do it right, there should be a single or a few header files, like /usr/include/btrfs.h or /usr/include/libbtrfs.h or /usr/include/btrfs/xyz.h, that export only the parts that are really necessary for an application that wants to use libbtrfs. Does it really make sense to have btrfs-progs expose things like ctree.h or crc32c.h or even list.h to userspace?! Another reason of my concerns is that I've been trying to work on exporting the equivalent of ioctl.h, with the constants and structs needed to call btrfs-specific ioctls, from the kernel side, I already submitted a patch to export it from a Linux kernel build as /usr/include/linux/btrfs.h. I believe that's the right way to export that particular information. The other part of it is synchronizing the header files (and to some extent some source files, like ctree.c) between the kernel and btrfs-progs. The current version of those headers (and C source files) in btrfs-progs was a copy of the same files from the kernel tree that was edited to compile in userspace and then diverged from the copy of the same files in the kernel. We should try to unify those (I sent another patch with a suggestion of a script that would update those from the kernel git tree.) Exposing those to userspace now would only muddle that situation more. If you think you can build a new header file that is clean and contain only the prototypes and constants and structs that are strictly required to export functions in a libbtrfs, then I'd fully support this patchset. If it's going to export all the header files as it's doing now, then I wouldn't... Thanks, Filipe -- 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
