On Mon, Jan 09, 2017 at 09:31:39AM -0600, Eric Sandeen wrote: > On 1/8/17 8:11 PM, Qu Wenruo wrote: > > > > > > At 01/08/2017 09:16 PM, Goldwyn Rodrigues wrote: > >> > >> 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. > > > > Personally speaking, I'm not a fan of re-using kernel code in btrfs-progs. > > But it already does re-use kernel code, it's just that the re-use is > extremely stale, with unfixed bugs in both directions as a result > (at least last time I looked.) > > > In fact, in btrfs-progs, we don't need a lot of kernel facilities, > > like page/VFS/lock(btrfs-progs works in single thread under most > > case). > > > > And that should make btrfs-progs easier to maintain. > > But as Goldwyn already pointed out, many bugs have gone un-fixed > in userspace, in code which was forked long ago from kernelspace. > > For things like locking it's trivial to define that away. > > xfsprogs does i.e. - > > /* miscellaneous kernel routines not in user space */ > #define down_read(a) ((void) 0) > #define up_read(a) ((void) 0) > #define spin_lock_init(a) ((void) 0) > #define spin_lock(a) ((void) 0) > #define spin_unlock(a) ((void) 0) > #define likely(x) (x) > #define unlikely(x) (x) > #define rcu_read_lock() ((void) 0) > #define rcu_read_unlock() ((void) 0) > #define WARN_ON_ONCE(expr) ((void) 0) > > > > Furthermore, there are cases while kernel is doing things wrong while > > btrfs-progs does it right. > > All the more reason to sync it up, fixes should always be in both > places, right? > > I had looked at this a few years ago, and started trying to sync things > up, but got daunted and busy and never completed anything. :( I sent > a few fixups back in April 2013 to get things /slightly/ closer. > > The libxfs sync in xfs has borne fruit; I'm of the opinion that similar > work would help btrfs too, though it can be a long road. > > (e2fsprogs has gone the other way, and has a completely separate > re-implementation in userspace; it works, I guess, but I have to say > that I really like the code commonality in xfs.) >
Yup, I also think we should be going in the XFS direction. It's a big maintenance burden to have to worry about the code in two places. (E.g., the biggest reason I haven't gotten around to implementing full free space tree support in btrfs-progs is that it's such a pain in the ass to port new kernel code to the outdated progs code.) As far as I know, the only reason it hasn't happened yet is that no one has agreed to do it, and we're all just hoping someone else will take care of it. -- 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
