Re: [RFC] Converging userspace and kernel code

[Omar Sandoval <osandov@osandov.com>]

On Tue, Jan 10, 2017 at 08:35:26AM +0800, Qu Wenruo wrote:
> That depends on how independent the "core" btrfs part is.
> 
> If completely independent,(Don't ever has any page/VFS/race code) I'm
> completely fine with that.
> 
> But the problem is, at least from current code base, even btrfs_path
> structure has quite a lot kernel facilities, mainly locks.
> (Just check the different size of btrfs_path in kernel and btrfs-progs)
> 
> So although the idea itself is very nice, but the practice may be quite
> hard.
> 
> That's why I prefer current btrfs-progs method, because it's more close to
> the core of btrfs algorithm, unlike kernel, which is a superset.
> In this case, I prefer to let kernel use and expand btrfs-progs code, other
> than pull in a superset from kernel.

[snip]

> While most of the bugs I found in RAID5/6 and dev-replace are all related to
> race, which doesn't ever exist in btrfs-progs.
> (That's why I love btrfs-progs so much than the kernel part)
> 
> So the problem is still how independent we can extract the core functions.
> 
> Thanks,
> Qu

I think you're getting too hung up on scrub/device replace. It doesn't
have to be an all-or-nothing thing. If the scrub code is too insane or
broken to pull in, then we can probably get away with a clean
reimplementation in btrfs-progs if we really want to. I think for a
majority of the Btrfs code, locking and other kernel-specific stuff
won't be too distracting. A good starting point might be the core B-tree
code.