1. Motivation While fixing user space tools for btrfs-progs, I found a couple of bugs which are already solved in kernel space but were not ported to user space. User space is a little ignored when it comes to fixing bugs in the core functionality. XFS developers have already performed this and the userspace and kernel code walks in lockstep for libxfs.
2. Implementation 2.1 Code Re-arranaging Re-arrange the kernel code so that core functions are in a separate directory "libbtrfs" or "core". (There is already libbtrfs_objects keyword defined in Makefile.in, so I am not sure if we should use libbtrfs, or perhaps just core). The core directory will contain algorithms, function prototypes and implementations spcific to btrfs. Comparing the current situation, ctree.h is pretty "polluted" with functions prototypes which do not belong there, the definition of which are not in ctree.c. An example: functions which use struct dentry, inode or other kernel component can be moved out of the core. Besides, functions which could survive with btrfs_inode as opposed to inode should be changed so. We would need new files to split the logic, such as creating inode.c to keep all inode related code. 2.2 Kernel Stubs Making the core directory a drop-in replacement will require kernel stubs which would make some meaning in user-space. This may or may not be included in kerncompat.h. Personally, I would prefer to move kerncompat.h into kernel-stub linux/*.h files. The down-side is we could have a lot of files and directories for stubs, not forgetting the ones for trace/*.h or event asm/*.h. 2.3 Flag day Flag day would be the day we move to the new directory structure. Until then, we send the patches with the current directory structure. After flag day, all patches must be ported to the new directory structure. We could request developers to repost/retest patches leading up to the flag day. 3. Post converging Checks/scripts to make sure that patches which are pushed to kernel space will not render user space tools uncompilable. While these are my (and my teams) thoughts, I would like suggestions and/or criticism to improve the idea. -- Goldwyn -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
