lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 9 Sep 2011 14:13:59 -0700
From:	"Luis R. Rodriguez" <mcgrof@...il.com>
To:	Julia Lawall <julia@...u.dk>
Cc:	Jesper Andersen <jespera@...u.dk>,
	Hauke Mehrtens <hauke@...ke-m.de>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Backporting the Linux kernel, for good - was: Re: semantic patch inference

On Fri, Sep 9, 2011 at 1:48 PM, Julia Lawall <julia@...u.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?

> 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ