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.mason@oracle.com>
Date: Fri May 29 16:35:30 2009 -0400
Mixed back reference (FORWARD ROLLING FORMAT CHANGE)
commit 5d4f98a28c7d334091c1b7744f48a1acdd2a4ae0
Author: Yan Zheng <zheng.yan@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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html