On Fri, Oct 19, 2012 at 4:40 AM, <[1]sf...@users.sourceforge.net> wrote:
[2]sf...@users.sourceforge.net:
> [3]sf...@users.sourceforge.net:
> > Matthijs Kooijman:
> > > I just tried to merge the aufs3.6 branch into the 3.6.2 kernel, which
> > > caused a merge failure. I'm not 100% sure if this is the right way to
> > > get with 3.6.2 with aufs, or where and how this should be fixed.
> > Â Â :::
> > > And here's the change that causes the conflict (copied from git diff
v3.6
> > > v3.6.2, I haven't pinpointed the revision it was introduced in:
> >
> > Confirmed.
> > $ git log1 v3.6..v3.6.2 fs/buffer.c
> > 92b7722 2012-10-13 ext4: fix mtime update in nodelalloc mode
> >
> >
> > > Fixing this seems simple enough, just move the two lines introduced by
aufs
> > > along wit the file_update_time call.
> >
> > Exactly.
> > In other words, aufs3.6 doesn't support linux-3.6.2.
>
> Hold it!
> I might be wrong.
> I will investigate this issue a day after next week.
Now I think I can see the story.
When we use aufs3-linux.git, and run "git pull" (or git merge) aufs3.6
into linux-3.6.2, we get
    CONFLICT (content): Merge conflict in fs/buffer.c
as Matthijs did.
(confrimed)
But if we use aufs3-standalone.git and apply the aufs3 patches manuall,
then we don't get the conflict.
    cd /usr/src/linux-3.6.2
    # $SRC is aufs3-standalone dir (full path)
    patch -p1 < $SRC/aufs3-kbuild.patch
    patch -p1 < $SRC/aufs3-base.patch
    patch -p1 < $SRC/aufs3-proc_map.patch
    patch -p1 < $SRC/aufs3-standalone.patch
as Tomas did.
(confrimed)
Note that aufs3-proc_map.patch is generated from aufs3.6, so the line
numbers in it don't match with linux-3.6.2. But clever "patch" command
silently solves the conflict and applies aufs3-proc_map.patch cleanly.
In other words, plain "patch" command looks more clever than "git
merge".
Hmm, should I create the branch aufs3.6.2?
But I don't wanna do that...
I think git rebase would be the proper way to apply aufs to a new kernel.
This applies the patches on top which not only ensures that they work (as
you have shown by applying them manually) but also ensures the patches can
be committed to that release of kernel on top.
git merge is the wrong thing to do I think if you ever hope to submit your
patches upstream.
Sam
References
1. mailto:sf...@users.sourceforge.net
2. mailto:sf...@users.sourceforge.net
3. mailto:sf...@users.sourceforge.net
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
