kernel: consolidated pull for developer experience

From: Richard Purdie <[email protected]>

In 1.8 we want to streamline the kernel build process. Basically we currently have multiple copies of the kernel source floating around and the copying/compression/decompression is painful.

Lets assume we have a kernel source per machine since in most cases this is true (and we have a sysroot per machine anyway). Basically, instead of extracting a source into WORKDIR, then copying to a sysroot, we now set S to point straight at STAGING_DIR_KERNEL.

Anything using kernel source can then just point at it and use:

do_configure[depends] += "virtual/kernel:do_patch"

to depend on the kernel source being present. Note this is different behaviour to DEPENDS += "virtual/kernel" which equates to do_configure[depends] += "virtual/kernel:do_populate_sysroot".

Once we do this, we no longer need the copy operation in do_populate_sysroot, in fact there is nothing to do there (yay).

The remaining part of the challenge is to kill off the horrible do_install. This patch splits it off to a different class, the idea here is to have a separate recipe which depends on the virtual/kernel:do_patch and just installs and packages the source needed to build modules on target into a specific package.

Right now this code is proof of concept. It builds kernels and kernel modules. perf blows up in do_package with issues on finding the kernel version which can probably be fixed by adding back the right bit of do_install, and adding a dependency of do_package[depends] += "virtual/kernel:do_install" to perf. The whole thing needs a good write up, the corner cases testing and probably a good dose of cleanup to the remaining code.

Signed-off-by Richard Purdie <[email protected]>

---
 meta/classes/kernel-yocto.bbclass      |  2 -
 meta/classes/kernel.bbclass            | 91 ++--------------------------------
 meta/classes/linux-kernel-base.bbclass | 13 ++++-
 meta/recipes-kernel/perf/perf.bb       | 12 ++---
 4 files changed, 20 insertions(+), 98 deletions(-)

meta/classes/kernel-yocto.bbclass +0 -2

index c3e24943bbaf..45bdc9670afe 100644
@@ -1,5 +1,3 @@
-S = "${WORKDIR}/linux"
-
 # remove tasks that modify the source tree in case externalsrc is inherited
 SRCTREECOVEREDTASKS += "do_kernel_link_vmlinux do_kernel_configme do_validate_branches do_kernel_configcheck do_kernel_checkout do_patch"
 

meta/classes/kernel.bbclass +3 -88

index fa06c3aae6f3..0d335a589121 100644
@@ -3,6 +3,8 @@ inherit linux-kernel-base kernel-module-split
 PROVIDES += "virtual/kernel"
 DEPENDS += "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}gcc kmod-native depmodwrapper-cross bc-native"
 
+S = "${STAGING_DIR_TARGET}/${KERNEL_SRC_PATH}"
+
 # we include gcc above, we dont need virtual/libc
 INHIBIT_DEFAULT_DEPS = "1"
 

@@ -55,7 +57,7 @@ KERNEL_IMAGEDEST = "boot"
 #
 export CMDLINE_CONSOLE = "console=${@d.getVar("KERNEL_CONSOLE",1) or "ttyS0"}"
 
-KERNEL_VERSION = "${@get_kernelversion('${B}')}"
+KERNEL_VERSION = "${@get_kernelversion_headers('${B}')}"
 
 KERNEL_LOCALVERSION ?= ""
 

@@ -221,93 +223,6 @@ kernel_do_install() {
        #
 
        echo "${KERNEL_VERSION}" > $kerneldir/kernel-abiversion
-
-       #
-       # Store kernel image name to allow use during image generation
-       #
-
-       echo "${KERNEL_IMAGE_BASE_NAME}" >$kerneldir/kernel-image-name
-
-       #
-       # Copy the entire source tree. In case an external build directory is
-       # used, copy the build directory over first, then copy over the source
-       # dir. This ensures the original Makefiles are used and not the
-       # redirecting Makefiles in the build directory.
-       #
-       find . -depth -not -name "*.cmd" -not -name "*.o" -not -name "*.so.dbg" -not -name "*.so" -not -path "./Documentation*" -not -path "./source*" -not -path "./.*" -print0 | cpio --null -pdlu $kerneldir
-       cp .config $kerneldir
-       if [ "${S}" != "${B}" ]; then
-               pwd="$PWD"
-               cd "${S}"
-               find . -depth -not -path "./Documentation*" -not -path "./.*" -print0 | cpio --null -pdlu $kerneldir
-               cd "$pwd"
-       fi
-
-       # Test to ensure that the output file and image type are not actually
-       # the same file. If hardlinking is used, they will be the same, and there's
-       # no need to install.
-       ! [ ${KERNEL_OUTPUT} -ef $kerneldir/${KERNEL_IMAGETYPE} ] && install -m 0644 ${KERNEL_OUTPUT} $kerneldir/${KERNEL_IMAGETYPE}
-       install -m 0644 System.map $kerneldir/System.map-${KERNEL_VERSION}
-
-       # Dummy Makefile so the clean below works
-        mkdir $kerneldir/Documentation
-        touch $kerneldir/Documentation/Makefile
-
-       #
-       # Clean and remove files not needed for building modules.
-       # Some distributions go through a lot more trouble to strip out
-       # unecessary headers, for now, we just prune the obvious bits.
-       #
-       # We don't want to leave host-arch binaries in /sysroots, so
-       # we clean the scripts dir while leaving the generated config
-       # and include files.
-       #
-       oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean _mrproper_scripts
-
-       # hide directories that shouldn't have their .c, s and S files deleted
-       for d in tools scripts lib; do
-               mv $kerneldir/$d $kerneldir/.$d
-       done
-
-       # delete .c, .s and .S files, unless we hid a directory as .<dir>. This technique is
-       # much faster than find -prune and -exec
-       find $kerneldir -not -path '*/\.*' -type f -name "*.[csS]" -delete
-
-       # put the hidden dirs back
-       for d in tools scripts lib; do
-               mv $kerneldir/.$d $kerneldir/$d
-       done
-
-       # As of Linux kernel version 3.0.1, the clean target removes
-       # arch/powerpc/lib/crtsavres.o which is present in
-       # KBUILD_LDFLAGS_MODULE, making it required to build external modules.
-       if [ ${ARCH} = "powerpc" ]; then
-               cp -l arch/powerpc/lib/crtsavres.o $kerneldir/arch/powerpc/lib/crtsavres.o
-       fi
-
-       # Necessary for building modules like compat-wireless.
-       if [ -f include/generated/bounds.h ]; then
-               cp -l include/generated/bounds.h $kerneldir/include/generated/bounds.h
-       fi
-       if [ -d arch/${ARCH}/include/generated ]; then
-               mkdir -p $kerneldir/arch/${ARCH}/include/generated/
-               cp -flR arch/${ARCH}/include/generated/* $kerneldir/arch/${ARCH}/include/generated/
-       fi
-
-       # Remove the following binaries which cause strip or arch QA errors
-       # during do_package for cross-compiled platforms
-       bin_files="arch/powerpc/boot/addnote arch/powerpc/boot/hack-coff \
-                  arch/powerpc/boot/mktree scripts/kconfig/zconf.tab.o \
-                  scripts/kconfig/conf.o scripts/kconfig/kxgettext.o"
-       for entry in $bin_files; do
-               rm -f $kerneldir/$entry
-       done
-
-       # kernels <2.6.30 don't have $kerneldir/tools directory so we check if it exists before calling sed
-       if [ -f $kerneldir/tools/perf/Makefile ]; then
-               # Fix SLANG_INC for slang.h
-               sed -i 's#-I/usr/include/slang#-I=/usr/include/slang#g' $kerneldir/tools/perf/Makefile
-       fi
 }
 do_install[prefuncs] += "package_get_auto_pr"
 

meta/classes/linux-kernel-base.bbclass +11 -2

index 4f2b0a4a9844..89ce71605c00 100644
@@ -1,5 +1,5 @@
 # parse kernel ABI version out of <linux/version.h>
-def get_kernelversion(p):
+def get_kernelversion_headers(p):
     import re
 
     fn = p + '/include/linux/utsrelease.h'

@@ -9,7 +9,6 @@ def get_kernelversion(p):
     if not os.path.isfile(fn):
         fn = p + '/include/linux/version.h'
 
-    import re
     try:
         f = open(fn, 'r')
     except IOError:

@@ -24,6 +23,16 @@ def get_kernelversion(p):
             return m.group(1)
     return None
 
+
+def get_kernelversion_file(p):
+    fn = p + '/kernel-abiversion'
+
+    try:
+        with open(fn, 'r') as f:
+            return f.readlines()[0].strip()
+    except IOError:
+        return None
+
 def linux_module_packages(s, d):
        suffix = ""
        return " ".join(map(lambda s: "kernel-module-%s%s" % (s.lower().replace('_', '-').replace('@', '+'), suffix), s.split()))

meta/recipes-kernel/perf/perf.bb +4 -2

index 3771cdb3e9dd..d375e246ce30 100644
@@ -22,7 +22,7 @@ TUI_DEPENDS = "${@perf_feature_enabled('perf-tui', 'libnewt slang', '',d)}"
 SCRIPTING_DEPENDS = "${@perf_feature_enabled('perf-scripting', 'perl python', '',d)}"
 LIBUNWIND_DEPENDS = "${@perf_feature_enabled('perf-libunwind', 'libunwind', '',d)}"
 
-DEPENDS = "virtual/kernel \
+DEPENDS = " \
     virtual/${MLPREFIX}libc \
     ${MLPREFIX}elfutils \
     ${MLPREFIX}binutils \

@@ -32,6 +32,8 @@ DEPENDS = "virtual/kernel \
     bison flex \
 "
 
+do_configure[depends] += "virtual/kernel:do_patch"
+
 PROVIDES = "virtual/perf"
 
 inherit linux-kernel-base kernel-arch pythonnative

@@ -46,7 +48,7 @@ export HOST_SYS
 #kernel 3.1+ supports WERROR to disable warnings as errors
 export WERROR = "0"
 
-do_populate_lic[depends] += "virtual/kernel:do_populate_sysroot"
+do_populate_lic[depends] += "virtual/kernel:do_patch"
 
 # needed for building the tools/perf Perl binding
 inherit perlnative cpan-base

meta/recipes-kernel/perf/perf.bb +1 -2

 B = "${WORKDIR}/${BPN}-${PV}"
 

@@ -157,7 +157,7 @@ do_configure_prepend () {
 }
 
 python do_package_prepend() {
-    bb.data.setVar('PKGV', get_kernelversion('${S}').split("-")[0], d)
+    d.setVar('PKGV', d.getVar("KERNEL_VERSION", True).split("-")[0])
 }
 
 PACKAGE_ARCH = "${MACHINE_ARCH}"
--

2.1.0

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Bruce Ashfield <[email protected]>

meta/classes/kernel.bbclass kernel_do_install() { · line 230

Quoted 12 lines · writes:

With the kernel build optimizations, we no longer copy the source from the built kernel into the staging dir, since the kernel is unpacked and built directly from the staging dir.

This means that a few build artifacts need to be restored to allow out of tree modules to once again build.
...

meta/classes/kernel.bbclass +5 -0

+	
+	# Copy files required for module builds
+	cp System.map $kerneldir/System.map-${KERNEL_VERSION}
+	cp Module.symvers $kerneldir/
+	cp .config $kerneldir/

This and the following lines seem to void the whole idea of the patchset because it means that only one kernel can be built. In our usecase we build usually two kernels: a full featured one for the main system and a minimal, initramfs based for a rescue system.

With this change and building both kernels, it is ambiguous which System.map is used.

Quoted 5 lines

In our usecase we build usually two kernels: a full featured one for the main system and a minimal, initramfs based for a rescue system.

With this change and building both kernels, it is ambiguous which System.map is used.

Regardless of how you do this, if you build two kernels, you still need to choose one to build the main set of modules against. I'm therefore not sure how this change makes anything particularly worst than what existed before?

Building two kernels is currently fraught with difficulty anyway,

to the point of not being a currently well supported use case and the classes would probably need to be refactored to allow such things to be well supported. These changes do bring significant benefit

Quoted 3 lines · Richard Purdie

to the point of not being a currently well supported use case and the classes would probably need to be refactored to allow such things to be well supported. These changes do bring significant benefit

Does some lowered i/o really provide such a benefit? With the new system you are bypassing the excellent staging system (which would detect e g ".config" or "System.map" file conflicts). Afais, it breaks with "rm_work" too (I guess, kernel:fetch stamp is removed when kernel build finishes and packages which inherit "kernelsrc" fetch the kernel sources (without .config and System.map) again).

In summary, basically, yes. The kernel source is huge and we were compressing/decompressing it in several places on the critical path. People were struggling to develop kernels using the system due to the overhead.

Whilst this approach does bypass some parts of the system, I do believe the benefits are worth it. We're talking about making the kernel build time about three times faster iirc,

Quoted 4 lines · Richard Purdie

In summary, basically, yes. The kernel source is huge and we were compressing/decompressing it in several places on the critical path. People were struggling to develop kernels using the system due to the overhead.

I do not see how the new system makes it easier to "develop kernels".

Due
to polluting sources with .config and related files, KBUILD_OUTPUT/VPATH builds are not possible from this tree.

In my experience, it is also a pain to jump between the different directories and tools like 'cscope' are not prepared of it.

And more importantly: the new system lowers end user experience significantly because kernel messages will show absolute buildsystem paths now; e.g.

| /srv/.oe/bld/e6ca2c38-c20d-f57f-7eca-ffc0aaa2f0bd/sysroots/kk-trizeps6/usr/src/kernel/drivers/usb/core/hub.c

vs.

| drivers/usb/core/hub.c

VPATH builds might be interesting for QA (e.g. building from same source with different configuration) but should not be used for final builds.

Quoted 3 lines

Whilst this approach does bypass some parts of the system, I do believe the benefits are worth it. We're talking about making the kernel build time about three times faster iirc,

I can not reproduce these numbers here; I get (after a '-c cleanall' and 'ccache -c'):

  | Task                         | time (old) | time (new) |
  |------------------------------+------------+------------|
  | do_bundle_initramfs          |   0.087052 |   0.034955 |
  | do_compile                   | 128.242407 | 133.723027 |
  | do_compile_kernelmodules     |  84.415655 |  83.249409 |
  | do_compile_prepare           |   2.885401 |   1.714159 |
  | do_configure                 |   6.202691 |   4.340526 |
  | do_deploy                    |  13.991785 |   14.07096 |
  | do_fetch                     |   0.210244 |   1.425304 |
  | do_generate_initramfs_source |   0.063915 |   0.041925 |
  | do_install                   |  16.190504 |    2.91906 |
  | do_package                   | 120.823374 |  16.422429 |
  | do_package_qa                |            |   2.557622 |
  | do_package_write_ipk         |   42.50694 |   29.57585 |
  | do_packagedata               |   1.612542 |   0.462001 |
  | do_patch                     |   0.186583 |   0.011232 |
  | do_populate_lic              |   0.795013 |   0.135186 |
  | do_populate_sysroot          |  10.142978 |   0.533519 |
  | do_rm_work                   |   1.762486 |   0.447187 |
  | do_rm_work_all               |   0.049144 |   0.030964 |
  | do_sizecheck                 |   0.054441 |   0.035806 |
  | do_strip                     |   0.049917 |   0.030841 |
  | do_uboot_mkimage             |   9.032543 |   12.83624 |
  | do_unpack                    |   6.695678 |   9.322173 |

  | old | 446.00129 |
  | new | 313.92038 |

Although the 'new' system is faster, this is gained mainly by the 'do_package' task which does not seem to be comparable. The new method will create only a very small 'kernel-dev' subpackage:

   1,1M    tmp/deploy/ipk/kk_trizeps6/kernel-dev_3.14...

vs.

    36M    tmp/deploy/ipk/kk_trizeps6/kernel-dev_3.14...

so the old task can be improved either by removing some files, or the new task misses files.

Quoted 6 lines

Quoted 4 lines

In summary, basically, yes. The kernel source is huge and we were compressing/decompressing it in several places on the critical path. People were struggling to develop kernels using the system due to the overhead.

I do not see how the new system makes it easier to "develop kernels".

One of the complaints I keep hearing is how long the populate_sysroot and package tasks take. I also get complaints about the sstate footprint of those tasks.

Imagine you're doing a "bitbake virtual/kernel -c compile -f", hacking on a module, you then package and install it onto the target to test.

Quoted 2 lines

to polluting sources with .config and related files, KBUILD_OUTPUT/VPATH builds are not possible from this tree.

Agreed and I'm actually not happy about this. I think going forward we'll need a second directory for these so we do keep the output separate and can recompile against it.

Quoted 10 lines · Richard Purdie

Quoted 6 lines

Quoted 4 lines

In summary, basically, yes. The kernel source is huge and we were compressing/decompressing it in several places on the critical path. People were struggling to develop kernels using the system due to the overhead.

I do not see how the new system makes it easier to "develop kernels".

One of the complaints I keep hearing is how long the populate_sysroot and package tasks take. I also get complaints about the sstate footprint of those tasks.

Perhaps, it should be possible to disable sstate'ing for certain recipes? In case of the new kernel build system, you swap the expensive sstate'ing with an expensive unpacking.

Quoted 2 lines

Imagine you're doing a "bitbake virtual/kernel -c compile -f", hacking on a module, you then package and install it onto the target to test.

1. Are there really people who are doing such things? There are much more effective ways to do kernel development with OE (you have the overhead from bitbake reading its database; do_compile() does not deploy images on TFTP server nor the modules in the NFS sysroot).

2. This usecase is not supported by the current classes:

1. the 'bitbake virtual/kernel -c compile -f' removes .config and System.map from the kernel sources (else, do_compile() will fail)

2. trying to build the module (with 'M=...')will fail because .config
+ System.map are missing in the source

Quoted 8 lines

Quoted 4 lines

to polluting sources with .config and related files, KBUILD_OUTPUT/VPATH builds are not possible from this tree.

Agreed and I'm actually not happy about this. I think going forward we'll need a second directory for these so we do keep the output separate and can recompile against it.

'cp -al' a template kernel and .config etc. into ${WORKDIR} should be pretty fast.

Enrico
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Quoted 8 lines · Enrico Scholz

Quoted 4 lines · Richard Purdie

In summary, basically, yes. The kernel source is huge and we were compressing/decompressing it in several places on the critical path. People were struggling to develop kernels using the system due to the overhead.

I do not see how the new system makes it easier to "develop kernels".

One of the complaints I keep hearing is how long the populate_sysroot and package tasks take. I also get complaints about the sstate footprint of those tasks.

Imagine you're doing a "bitbake virtual/kernel -c compile -f", hacking on a module, you then package and install it onto the target to test.

As things stood, the package and populate_sysroot tasks took a while (I'll get to times in a minute). This was particularly true with large kernel source directories.

We also had issues about how and when "make scripts" should be run on the kernel directory to enable module building and conflicts over people wanting the source code to be able to develop modules on target. Not everyone wants the latter but it should be available to those who do want it and the old kernel-dev package was basically crippled.

Taking a step back from things and keeping in mind some of the "developer experience" goals of the 1.8 release, we therefore looked at how we could improve things. The biggest problem and overhead is the amount of copying of a large chunk of data (the kernel source) that we make and the fact that it was incomplete in kernel-dev due to wanting speed (at the expense of breaking it). The changes therefore look at improving things in that area.

Quoted 3 lines

Due
to polluting sources with .config and related files, KBUILD_OUTPUT/VPATH builds are not possible from this tree.

Agreed and I'm actually not happy about this. I think going forward we'll need a second directory for these so we do keep the output separate and can recompile against it. Bruce, please take note we probably need to change this.

Quoted 8 lines

In my experience, it is also a pain to jump between the different directories and tools like 'cscope' are not prepared of it.

And more importantly: the new system lowers end user experience significantly because kernel messages will show absolute buildsystem paths now; e.g.

Quoted 5 lines

| /srv/.oe/bld/e6ca2c38-c20d-f57f-7eca-ffc0aaa2f0bd/sysroots/kk-trizeps6/usr/src/kernel/drivers/usb/core/hub.c

vs.

| drivers/usb/core/hub.c

See my other email on the two sides to this. Here I can tell from a cut and pasted failure which revisions you were trying to build so it actually makes the logs more useful in some contexts. That isn't the reason we've done this but I'd say it can be helpful.

Quoted 7 lines

VPATH builds might be interesting for QA (e.g. building from same source with different configuration) but should not be used for final builds.

Quoted 3 lines

Whilst this approach does bypass some parts of the system, I do believe the benefits are worth it. We're talking about making the kernel build time about three times faster iirc,

I did say "iirc" and I don't exactly remember the circumstances I tested that, see below, sorry :(.

Quoted 28 lines

I can not reproduce these numbers here; I get (after a '-c cleanall' and 'ccache -c'):

  | Task                         | time (old) | time (new) |
  |------------------------------+------------+------------|
  | do_bundle_initramfs          |   0.087052 |   0.034955 |
  | do_compile                   | 128.242407 | 133.723027 |
  | do_compile_kernelmodules     |  84.415655 |  83.249409 |
  | do_compile_prepare           |   2.885401 |   1.714159 |
  | do_configure                 |   6.202691 |   4.340526 |
  | do_deploy                    |  13.991785 |   14.07096 |
  | do_fetch                     |   0.210244 |   1.425304 |
  | do_generate_initramfs_source |   0.063915 |   0.041925 |
  | do_install                   |  16.190504 |    2.91906 |
  | do_package                   | 120.823374 |  16.422429 |
  | do_package_qa                |            |   2.557622 |
  | do_package_write_ipk         |   42.50694 |   29.57585 |
  | do_packagedata               |   1.612542 |   0.462001 |
  | do_patch                     |   0.186583 |   0.011232 |
  | do_populate_lic              |   0.795013 |   0.135186 |
  | do_populate_sysroot          |  10.142978 |   0.533519 |
  | do_rm_work                   |   1.762486 |   0.447187 |
  | do_rm_work_all               |   0.049144 |   0.030964 |
  | do_sizecheck                 |   0.054441 |   0.035806 |
  | do_strip                     |   0.049917 |   0.030841 |
  | do_uboot_mkimage             |   9.032543 |   12.83624 |
  | do_unpack                    |   6.695678 |   9.322173 |

Quoted 2 lines

  | old | 446.00129 |
  | new | 313.92038 |

So you have a gain here from 7.4 mins to 5.2 mins which isn't bad. I'd observe your numbers suggest you have pretty fast disk IO, I've seen the populate_sysroot task take a lot longer due to the amount of data being copied around. Keep in mind that whilst do_package improved, so did package_write_ipk, rm_work, install and populate_sysroot, all quite a bit more than "three times".

I suspect my "three times" number comes from my highly parallel core system where the do_compile/do_compilemodules step runs extremely quickly (say 20s) but do_package was about the same as this so you can imagine if you reduce do_package from 120s to 16s, you could see an increase of about "three times".

To give another perspective on the times, we run "official" benchmarks of some things and the line before and after the changes merged from that log is:

fedora19,master:88528a128fe7c11871c24706ff6d245b183d6975,1.7_M2-1510-g88528a1,1:18:03,11:16.26,1:13:35,4:11.18,0:34.68,0:15.72,0:01.08,24805964,5548960 fedora19,master:b99419ff4c1b5ac1e4acd34d95fffd3ac5458bad,1.7_M2-1553-gb99419f,1:13:20,8:10.41,1:10:07,4:08.31,0:34.67,0:15.77,0:01.05,24385880,5956872

What that shows is that:

The "bitbake core-image-sato -c rootfs" time without rm_work went from 1:18 to 1:13, i.e. improved 5 mins.

The "bitbake virtual/kernel" time went from 11:16 to 8:10, i.e. improved by 3 mins.

The "bitbake core-image-sato -c rootfs" time with rm_work went from 1:13 to 1:10, i.e. improved 3 mins.

and the size of the build with rm_work increased by around 500MB, the size of the build without rm_work decreased by 500MB.

I will also add that we're not done yet with some of these tweaks. I know linux-yocto is doing some things in do_patch that are performance intensive and we plan to fix those which will further improve the 11 mins number above.

Quoted 4 lines

Although the 'new' system is faster, this is gained mainly by the 'do_package' task which does not seem to be comparable. The new method will create only a very small 'kernel-dev' subpackage:

Quoted 8 lines

   1,1M    tmp/deploy/ipk/kk_trizeps6/kernel-dev_3.14...

vs.

    36M    tmp/deploy/ipk/kk_trizeps6/kernel-dev_3.14...

so the old task can be improved either by removing some files, or the new task misses files.

There is a new kernel-devsrc package which contains some things that used to be in kernel-dev. It is way more complete and functional than the old one ever was since the old one was a hacked up copy of the kernel source. It also only gets built if you request it, only a small number of people need it and its hence much more user friendly this way.

I am sorry you're not happy about the changes :(.

Cheers,

Richard

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core