On Mon, Apr 30, 2012 at 11:42:44AM -0700, H. Peter Anvin wrote:
> On 04/30/2012 06:30 AM, Greg KH wrote:
> > On Mon, Apr 30, 2012 at 01:37:09PM +0100, Ben Hutchings wrote:
> >> On Sun, 2012-04-29 at 17:19 -0700, [email protected] wrote:
> >>> The patch below does not apply to the 3.3-stable tree.
> >>> If someone wants it applied there, or to any other stable or longterm
> >>> tree, then please email the backport, including the original git commit
> >>> id to <[email protected]>.
> >> [...]
> >>
> >> Having just backported the EFI stub feature to 3.2, I can say that
> >> you'll need to cherry-pick these in front of it:
> >>
> >> c7b738351ba92f48b943ac59aff6b5b0f17f37c9 x86, efi: Fix pointer math issue
> >> in handle_ramdisks()
> >> a07f7672d7cf0ff0d6e548a9feb6e0bd016d9c6c tools/include: Add byteshift
> >> headers for endian access
> >> 12871c568305a0b20f116315479a18cd46882e9b x86, mkpiggy: Don't open code
> >> put_unaligned_le32()
> >> d40f833630a1299fd377408dc8d8fac370d621b0 x86, boot: Restrict CFLAGS for
> >> hostprogs
> >> 92f42c50f227ad228f815a8f4eec872524dae3a5 x86, efi: Fix endian issues and
> >> unaligned accesses
> >> 446e1c86d51d0823e003a43a2b85c430efce2733 x86, boot: Correct CFLAGS for
> >> hostprogs
> >
> > Hm, are these all really "needed" for 3.3 then? I'll be glad to queue
> > them up, but with the advent of 3.4 pretty soon now, is this necessary?
> >
>
> I don't think we need that for a 3.3 backport of the patch. I think
> it's the changes to tools/build.c that bite you.
Sure, it is possible to backport this in isolation by removing
the use of <tools/le_aligned.h>. However the above series lets us use
cherry-picked unmodified patches, which is generally preferable for
stable. But I don't have a strong opinion on this, and it's Greg's
decision.
Ben.
> Let me see if I can whip up a quick backport.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
