[PATCH 0/1] RFC: provide 3.0.x and 3.1 libc headers

[PATCH 0/1] RFC: provide 3.0.x and 3.1 libc headers

[Bruce Ashfield]

Hi all,

Here's a RFC patch for updating the toolchain linux-libc headers to 3.x
variants.

The reason I'm calling it a RFC is:

  - I wrote some anonymous python code (and I'm no python coder) to
    deal with 2.6 / 3.0 tgz location differences. This could have
    also been done with a variable set in the recipes and used by
    the .inc. I wasn't sure of the preferred approach, hence the RFC.
    I'll take no offense corrections here.

  - I changed the .inc, but didn't bump the PR of the existing recipes
    and didn't remove the existing 2.6 variants. If either of these
    should have been done, let me know and I'll respin.

  - I bumped the default to be 3.1. If that's too agressive for the
    default, and we'd prefer 3.0.8, let me know and I'll respin.

I built and booted all the qemu machines with the 3.1 kernel headers.  So
from the testing I was able to do, this looks to be safe and ready to go.

This is based on my yocto repo, I also did the changes in my oe-core
repository, but I don't have a oe-core contrib branch that I could push to,
so I chose to send the yocto variant. If someone points me to who I email for
an oe-core contrib branch, I can push that variant as well.

Cheers,

Bruce


The following changes since commit fc94f925e848684244a38dcffe15cb1192dfbed8:
  Martin Jansa (1):
        libxml-parser-perl, libxml-simple-perl, expat, sgmlspl-native, git: bump PR to rebuild after perl upgrade

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib zedd/libc-headers
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/libc-headers

Bruce Ashfield (1):
  linux-libc-headers: provide 3.0.x and 3.1 headers

 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

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

[Bruce Ashfield]

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@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)
+}
+
+SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/linux-${PV}.tar.bz2"
 
 #DEPENDS = "cross-linkage"
 RDEPENDS_${PN}-dev = ""
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.0.8.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.0.8.bb
new file mode 100644
index 0000000..3c845ef
--- /dev/null
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.0.8.bb
@@ -0,0 +1,53 @@
+require linux-libc-headers.inc
+
+INHIBIT_DEFAULT_DEPS = "1"
+DEPENDS += "unifdef-native"
+PR = "r1"
+
+SRC_URI += " file://connector-msg-size-fix.patch"
+
+S = "${WORKDIR}/linux-${PV}"
+
+set_arch() {
+	case ${TARGET_ARCH} in
+		alpha*)   ARCH=alpha ;;
+		arm*)     ARCH=arm ;;
+		cris*)    ARCH=cris ;;
+		hppa*)    ARCH=parisc ;;
+		i*86*)    ARCH=i386 ;;
+		ia64*)    ARCH=ia64 ;;
+		mips*)    ARCH=mips ;;
+		m68k*)    ARCH=m68k ;;
+		powerpc*) ARCH=powerpc ;;
+		s390*)    ARCH=s390 ;;
+		sh*)      ARCH=sh ;;
+		sparc64*) ARCH=sparc64 ;;
+		sparc*)   ARCH=sparc ;;
+		x86_64*)  ARCH=x86_64 ;;
+		avr32*)   ARCH=avr32 ;;
+		bfin*)    ARCH=blackfin ;;
+		microblaze*) ARCH=microblaze ;;
+	esac
+}
+
+do_configure() {
+	set_arch
+	oe_runmake allnoconfig ARCH=$ARCH
+}
+
+do_compile () {
+}
+
+do_install() {
+	set_arch
+	oe_runmake headers_install INSTALL_HDR_PATH=${D}${exec_prefix} ARCH=$ARCH
+	# Kernel should not be exporting this header
+	rm -f ${D}${exec_prefix}/include/scsi/scsi.h
+
+	# The ..install.cmd conflicts between various configure runs
+	find ${D}${includedir} -name ..install.cmd | xargs rm -f
+}
+
+BBCLASSEXTEND = "nativesdk"
+SRC_URI[md5sum] = "eac4d398a0ecd98214487cd47a228998"
+SRC_URI[sha256sum] = "4ed16da319848f681f711dbda2ac2cf1b306a280ec22f90bae190cf23b533add"
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.1.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.1.bb
new file mode 100644
index 0000000..5f9fe64
--- /dev/null
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.1.bb
@@ -0,0 +1,53 @@
+require linux-libc-headers.inc
+
+INHIBIT_DEFAULT_DEPS = "1"
+DEPENDS += "unifdef-native"
+PR = "r1"
+
+SRC_URI += " file://connector-msg-size-fix.patch"
+
+S = "${WORKDIR}/linux-${PV}"
+
+set_arch() {
+	case ${TARGET_ARCH} in
+		alpha*)   ARCH=alpha ;;
+		arm*)     ARCH=arm ;;
+		cris*)    ARCH=cris ;;
+		hppa*)    ARCH=parisc ;;
+		i*86*)    ARCH=i386 ;;
+		ia64*)    ARCH=ia64 ;;
+		mips*)    ARCH=mips ;;
+		m68k*)    ARCH=m68k ;;
+		powerpc*) ARCH=powerpc ;;
+		s390*)    ARCH=s390 ;;
+		sh*)      ARCH=sh ;;
+		sparc64*) ARCH=sparc64 ;;
+		sparc*)   ARCH=sparc ;;
+		x86_64*)  ARCH=x86_64 ;;
+		avr32*)   ARCH=avr32 ;;
+		bfin*)    ARCH=blackfin ;;
+		microblaze*) ARCH=microblaze ;;
+	esac
+}
+
+do_configure() {
+	set_arch
+	oe_runmake allnoconfig ARCH=$ARCH
+}
+
+do_compile () {
+}
+
+do_install() {
+	set_arch
+	oe_runmake headers_install INSTALL_HDR_PATH=${D}${exec_prefix} ARCH=$ARCH
+	# Kernel should not be exporting this header
+	rm -f ${D}${exec_prefix}/include/scsi/scsi.h
+
+	# The ..install.cmd conflicts between various configure runs
+	find ${D}${includedir} -name ..install.cmd | xargs rm -f
+}
+
+BBCLASSEXTEND = "nativesdk"
+SRC_URI[md5sum] = "8d43453f8159b2332ad410b19d86a931"
+SRC_URI[sha256sum] = "2573d2378c754b0c602b57586e9311e5b38c5d1e6c137f02873833633a4b9359"
-- 
1.7.0.4

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

[Richard Purdie]

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@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

Can someone please explain to me why we don't move some of the bits in
the .bb file into the .inc rather than duplicating it each time?

Cheers,

Richard

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

[Bruce Ashfield]

On 11-10-26 04:25 PM, Richard Purdie 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@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
>
> Can someone please explain to me why we don't move some of the bits in
> the .bb file into the .inc rather than duplicating it each time?

I wondered the same thing. I can refactor it if no one
objects.

Bruce

>
> Cheers,
>
> Richard
>

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

[Richard Purdie]

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@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.

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?

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!

Cheers,

Richard

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

[Anders Darander]

* Richard Purdie <richard.purdie@linuxfoundation.org> [111026 23:02]:
> 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.

> 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?

Don't we have 2.6-kernel left? If so, I guess that we ought to leave the
2.6 versions of the recipe. At least if I remember correctly in that a
userspace compiled against a certain version of kernel headers should
run OK on a newer kernel, but isn't guarenteed to run OK on an older
kernel. Correct me if I'm wrong...

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB

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

[Anders Darander]

* Anders Darander <anders@chargestorm.se> [111026 23:14]:
> * Richard Purdie <richard.purdie@linuxfoundation.org> [111026 23:02]:
> > 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.

> > 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?

> Don't we have 2.6-kernel left? If so, I guess that we ought to leave the
> 2.6 versions of the recipe. At least if I remember correctly in that a
> userspace compiled against a certain version of kernel headers should
> run OK on a newer kernel, but isn't guarenteed to run OK on an older
> kernel. Correct me if I'm wrong...

Forget my reply above, I'm obviously not looking closely enough at the
patch. (Which tells me I'm getting tired and should get some
rest/sleep).

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB

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

[Bruce Ashfield]

On Wed, Oct 26, 2011 at 5:01 PM, Richard Purdie
<richard.purdie@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@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@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"