On 4/5/13 7:20 PM, Josef Bacik wrote: > On Fri, Apr 05, 2013 at 04:48:56PM -0600, Eric Sandeen wrote: >> One thing led to another in poking around the code, and I realized >> that while userspace has lots of code copied from the kernel, it >> was last copied in 2008, in many cases. ;) >> >> What's the plan here, how are userspace & kernelspace to be kept >> in sync? >> >> New features fairly obviously hit both, but what about bugfixes >> that hit one codebase or the other? >> >> Is it clear (to anyone) which code needs to be synced? >> >> Should it be done as a wholesale sync-up/rebase from time to >> time, or should commits be merged from one to the other? >> > > So having just had to bring back part of the free space cache code I'd say we > just cherry pick stuff since it is a huge pain to just copy it over, > especially > when you start talking about the extent buffer stuff. If maybe we could > seperate out the really kernel specific stuff (like the stuff that does the > reading/writing or interfaces with vfs) and the btrfs specific stuff then > maybe > it would be good to keep them in sync. But honestly I think the core stuff is > pretty solid right now so cherry-picking is probably our better bet. Thanks,
Some of it is just different style, but there seem to be some functional differences as well. >From some spot-checking, I found a few things that were kind of uh, what? Like comparing: commit 95d3f20b51e9b2ee21822313ad4f31279396407b Author: Chris Mason <chris.ma...@oracle.com> Date: Fri May 29 16:35:30 2009 -0400 Mixed back reference (FORWARD ROLLING FORMAT CHANGE) commit 5d4f98a28c7d334091c1b7744f48a1acdd2a4ae0 Author: Yan Zheng <zheng....@oracle.com> Date: Wed Jun 10 10:45:14 2009 -0400 Btrfs: Mixed back reference (FORWARD ROLLING FORMAT CHANGE) had differences like: convert_extent_item_v0, from userspace to kernelspace: - ret = btrfs_search_slot(trans, root, &key, path, new_size, 1); + ret = btrfs_search_slot(trans, root, &key, path, + new_size + extra_size, 1); Either that's incredibly subtle and undocumented, or just wrong in one case or the other? I mean, this is just one thing. Seems like a plan to keep it in sync is warranted, maybe keeping the kernel copies in separate files, so diffs make some semblance of sense? I dunno, I just worry about long-term maintainability of it all. -Eric > Josef > -- 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
