[OE-core] [PATCH 1/1] linux-libc-headers: provide 3.0.x and 3.1 headers

Bruce Ashfield bruce.ashfield at gmail.com
Thu Oct 27 00:53:17 UTC 2011


On Wed, Oct 26, 2011 at 5:01 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Wed, 2011-10-26 at 14:25 -0400, Bruce Ashfield wrote:
>> This changes makes two different 3.x headers available to the
>> toolchain. The latest 3.0.x and 3.1 tarballs. Compatibility is
>> maintained with older 2.6 headers by creating a new variable
>> that changes the SRC_URI based on the major version number of
>> the kernel.
>>
>> Tested with 2.6.37.2, 3.0.8 and 3.1 builds and boots.
>>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield at windriver.com>
>> ---
>>  meta/conf/distro/include/tcmode-default.inc        |    2 +-
>>  .../linux-libc-headers/linux-libc-headers.inc      |   15 +++++-
>>  .../linux-libc-headers/linux-libc-headers_3.0.8.bb |   53 ++++++++++++++++++++
>>  .../linux-libc-headers/linux-libc-headers_3.1.bb   |   53 ++++++++++++++++++++
>>  4 files changed, 120 insertions(+), 3 deletions(-)
>>  create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.0.8.bb
>>  create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.1.bb
>>
>> diff --git a/meta/conf/distro/include/tcmode-default.inc b/meta/conf/distro/include/tcmode-default.inc
>> index 2bf1beb..ed722be 100644
>> --- a/meta/conf/distro/include/tcmode-default.inc
>> +++ b/meta/conf/distro/include/tcmode-default.inc
>> @@ -21,7 +21,7 @@ SDKGCCVERSION ?= "4.6%"
>>  BINUVERSION ?= "2.21.1a"
>>  EGLIBCVERSION ?= "2.13"
>>  UCLIBCVERSION ?= "0.9.32"
>> -LINUXLIBCVERSION ?= "2.6.37.2"
>> +LINUXLIBCVERSION ?= "3.1"
>>
>>  # Temporary preferred version overrides for PPC
>>  PREFERRED_VERSION_u-boot-mkimage-native_powerpc ?= "2009.08"
>> diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>> index 014024f..4e874fe 100644
>> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>> @@ -1,9 +1,20 @@
>> -DESCRIPTION = "Sanitized set of 2.6 kernel headers for the C library's use."
>> +DESCRIPTION = "Sanitized set of kernel headers for the C library's use."
>>  SECTION = "devel"
>>  LICENSE = "GPLv2"
>>
>>  LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>> -SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v2.6/linux-${PV}.tar.bz2"
>> +
>> +python __anonymous () {
>> +    import bb, re, string
>> +
>> +    major = bb.data.getVar("PV",d,1).split('.')[0]
>> +    if major == "3":
>> +        bb.data.setVar("HEADER_FETCH_VER", "3.0", d)
>> +    else:
>> +        bb.data.setVar("HEADER_FETCH_VER", "2.6", d)
>> +}
>> +
>
> Just for reference, this kind of code whilst nice, does have a
> reasonable amount of overhead. For something which is effectively legacy
> setting MAJORVERSION = "3.0" in the recipe probably isn't a big deal.
>
> Also, please do d.getVar("PV", True) instead of the above. The "1" is
> bad and should be "True" and its neater to access d's getVar method
> directly now. I appreciate there is a lot of older code but any new code
> should use this approach.

Ack'd. I stole this from an old example, so I propagated a crime. I can
fix it up and send v3.  I was a bit worried about users of the .inc I
couldn't see, so I think I'll keep the python code around (unless I hear
a strong objection) for now, and we can slate it to be killed off entirely
in the future.

>
> There is also no need to import string (since its unused) and bb above
> (since its already always included).
>
> In answer to your other question, its probably safe to drop the older
> versions and switch to 3.1 at this point unless there are known
> compatibility issues?

I don't know of any, everything worked here. So I'll spin a 3 part
series, update, addition and removal and I'll leave it up to you about which
parts you want.

>
> My other comment about moving code to the .inc also stands and I didn't
> intend to sound as grumpy as it does when I read it back!

No worries. I didn't read it that way either!

Bruce

>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"




More information about the Openembedded-core mailing list