Re: Backporting the Linux kernel, for good - was: Re: semantic patch inference

[Julia Lawall <julia@diku.dk>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1838 bytes --]

On Fri, 9 Sep 2011, Luis R. Rodriguez wrote:

> On Fri, Sep 9, 2011 at 1:48 PM, Julia Lawall <julia@diku.dk> wrote:
> > Thanks for your email.  It made me realize that there was one thing that I
> > didn't understand at all.  If the patches are only intended to apply to
> > linux-next, that makes the problem quite a bit simpler.
> 
> Awesome, and yes the patches/ are only targeted at applying onto
> linux-next.git. When Linus decides to merge and out 3.x-rc1 I simply
> then set $GIT_TREE to $HOME/linux-2.6-allstable/ and run the script to
> suck code from there and apply patches from there.Turns out that
> because the effort was done on linux-next and because linux-next will
> look very much like what Linus ends up merging the patches/ will still
> apply. So what I do then is simply create a branch for that target
> stable kernel and keep refreshing the patches for that stable kernel
> on that branch -- while the master branch keeps chugging along with
> linux-next.
> 
> > I guess that the patch that spdiff will receive will already contain the
> > appropriate #ifs, so we don't have to be concerned about them.
> 
> That is correct.
> 
> > We just add them in as is.
> 
> I do not follow, add what?

Sorry.  The + code. The #ifdefs ad the compatibility code.  We don't have 
to interpret it, so we don't care whether it is only related to kernel 
version numbers or something more complex.

julia

> > There was also the question about one or multiple types of changes.  I
> > think this is not a problem, but Jesper should confirm.  If a patch contains
> > two changes and one can be generalized and the other one cannot for some
> > reason, does spdiff give up on the whole thing, or does it do what it can?
> >
> > Overall, the whole thing seems to be doable :)
> 
> Wow. I'm thrilled, so say the least.
> 
>   Luis
>