How are userspace & kernelspace kept in sync?

How are userspace & kernelspace kept in sync?

[Eric Sandeen]

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?

Just wondering,
Thanks,
-Eric

Re: How are userspace & kernelspace kept in sync?

[Josef Bacik]

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,

Josef 

Re: How are userspace & kernelspace kept in sync?

[Eric Sandeen]

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 
>