7095 2014-12-20 11:18:22 +0000 Can't install kernel-dev and kernel-devsrc together 2016-07-29 16:00:33 +0000 1 1 6 Yocto Project Subprojects Kernel linux-yocto unspecified x86 Multiple RESOLVED FIXED Medium+ normal 2.2 M2 1 richard.purdie bruce.ashfield bruce.ashfield dvhart jose.perez.carranza juro.bystricky net147 sgw tom.zanussi david.israelx.rodriguez.castellanos --- --- No (bug/feature does not impact docs) oldest_to_newest 47646 0 richard.purdie 2014-12-20 11:18:22 +0000 If you try and install kernel-dev and kernel-devsrc into the same image you can't since they have overlapping files. For now I tweaked core-image-sato-sdk just to install kernel-devsrc but this needs to be fixed. 47771 1 dvhart 2015-01-07 19:58:08 +0000 So these packages serve different purposes. kernel-dev allows for building out-of-tree modules by including headers, sources, and generated files necessary for that task. The vmlinux and such are also useful for other debugging tasks independent from module building. kernel-devsrc provides the complete kernel source. As they serve different purposes, we should be able to install them to different locations. Debian uses a similar approach with: linux-headers-*: this package aligns with kernel-dev and installs to /usr/src/linux-headers-<VERSION>-(common|<ARCH>) linux-sourc-*: this package is analogous to kernel-devsrc, and includes a tarball of the sources as well as a set of configurations, installed to /usr/src/linux-source* and /usr/src/linux-config*. This split makes sense to me and seems to mirror our requirements pretty well. Any objections to resolving this issue by having the two packages install to different /usr/src/* locations? 47772 2 bruce.ashfield 2015-01-07 20:08:06 +0000 No objection here. I can live with that. We have almost no users of the new recipes/names, so the switch should be straight forward from that point of view. 47773 3 bruce.ashfield 2015-01-07 20:11:18 +0000 There is still some overlap in the packages, since you can also build modules against kernel-devsrc. Does our debian example have the capability of building modules against both the headers and the source ? If we have the capability of building modules against both .. do we run the risk of them getting out of sync ? 47777 4 dvhart 2015-01-07 21:32:44 +0000 The Debian example installs a tarball of the source, so specifically not intended to build modules. I don't think devsrc should either. 47778 5 bruce.ashfield 2015-01-07 21:35:00 +0000 But one of the goals of devsrc is that you can install it, and build the entire kernel on the target. If you can do that, you can build modules. We need a package that has that capability. So either it is added to the headers (which seems wrong), or it is part of devsrc. 47779 6 richard.purdie 2015-01-07 21:43:19 +0000 I believe that we do need to split these into two locations, but there still should not be an overlap of files between them. kernel-devsrc is the kernel source code. kernel-dev should probably become a "kernel-buildconfig" type package containing the build artifacts like the defconfig, System.map file and other key components needed for the build of modules (other than the source). Basically, kernel-devvsrc is work-shared/MACHINE/kernel-source and kernel-dev would have the do_shared_workdir parts of work-shared/MACHINE/kernel-build (but not the make scripts ones). We do need to figure out the "make scripts" part at some later date, if may also become part of kernel-dev. Fixing this bug is hard right now with the single usr/src/kernel dir, once we split it, this should become much easier. 47782 7 dvhart 2015-01-07 22:01:06 +0000 Hrm.... so this packages things as they are on the host effectively, and I can see the appeal there. The typical distro considers these two packages to be very different things and they provide partially duplicated data (ascii ven diagram, without the circles): linux-headers both linux-source ============= ==== ============ headers config systemmap all source files generated files linux-headers is a minimal subset of the sources, plus any necessary generated files. This fills the "build out of tree modules against the running kernel" requirement. The full source is also available for rebuilding the full kernel, patching, etc. Debian splits out headers and generated files with the source and build symlinks to common and arch dirs respectively. The linux-source package provides config and a tarball. I can see this appealing to users as they only get as much as they require with each package. In order to improve our build time, it sounds like the proposal from Richard is to forgo the manual pruning of only the required bits, and require the use of the complete source for the build external modules use case. I suspect we'll have users that care about each use case, and some of those that just want to build modules really won't want to have to install all the sources. 47816 8 richard.purdie 2015-01-08 20:52:37 +0000 How is the "minimal subset of the sources" built? It his the make install_headers or whatever linux-libc-headers does? 52918 9 2642 juro.bystricky 2015-08-08 17:33:41 +0000 Created attachment 2642 kernel.bbclass patch to populate kernel-dev 52919 10 juro.bystricky 2015-08-08 17:34:22 +0000 A typical out-of-tree kernel module build process is described in http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html The build relies on the existence of "/lib/modules/<kernel-version>/build", containing (or symlink to) a necessary set of kernel development files. This necessary set should be provided by kernel-dev. The subset should be located at /lib/modules/<kernel-version>/build directly or at a location specified by the symlink (which at present should be something else then /usr/src/<kernel-version>): /lib/modules/<kernel-version>/build->/usr/src/<kernel-headers> Typical content of the subset can be seen here: https://www.archlinux.org/packages/core/i686/linux-headers/ Users usually install these "kernel-headers" or "linux-headers" via # apt-get install linux-headers-$(uname -r) The easiest way to support both kernel-dev and kernel-devsrc at the same time is to make sure they don't reside at the same place. Of course this could be optimized, as the bulk of all files for kernel-dev and kernel-devsrc is identical. (see the attached patch for kernel.bbclass as one possible way to implement kernel-dev) 54638 11 bruce.ashfield 2015-09-24 16:55:43 +0000 This won't make 2.0, so I'm bumping it to 2.1 (even though this is assigned to Darren). I have some preliminary work on this, so targeting M1 seems reasonable. 60240 12 bruce.ashfield 2016-03-21 23:22:53 +0000 The implementation of this @ Wind River, showed some compatibility issues and isn't aligned with any defacto standard (or standard) at all. I'm going to take the implementation of this myself, and move it to 2.2 60384 13 bruce.ashfield 2016-03-24 13:37:59 +0000 I'm now able to install both at the same time, further testing required, but the basics are in place. 60405 14 bruce.ashfield 2016-03-24 17:03:40 +0000 Packaging and contents aside, we can now install both: root@qemux86-64:~# opkg list |grep kernel kernel-4.4.3-yocto-standard - 4.4.3+git0+194a6c1c4b_3d2455f9da-r0 kernel-dev - 4.4.3+git0+194a6c1c4b_3d2455f9da-r0 kernel-devsrc - 1.0-r0 kernel-module-uvesafb - 4.4.3+git0+194a6c1c4b_3d2455f9da-r0 This is a core image minimal with:: CORE_IMAGE_EXTRA_INSTALL = " kernel-dev kernel-devsrc perf perf-python" PERF_FEATURES_ENABLE += "perf-scripting perf-tui" IMAGE_FEATURES += "package-management" 61022 15 juro.bystricky 2016-04-11 16:16:21 +0000 Works fine, both kernel-dev, kernel-devsrc co-exist peacefully. Tested with a modified build-appliance-image https://bugzilla.yoctoproject.org/show_bug.cgi?id=8073 where I was able to build out-of-tree-kernel module. 2642 2015-08-08 17:33:41 +0000 2015-08-08 17:33:41 +0000 kernel.bbclass patch to populate kernel-dev kernel.bbclass.patch text/plain 1181 juro.bystricky ZGlmZiAtLWdpdCBhL21ldGEvY2xhc3Nlcy9rZXJuZWwuYmJjbGFzcyBiL21ldGEvY2xhc3Nlcy9r ZXJuZWwuYmJjbGFzcwppbmRleCBkMDZmNmNmLi5jNDhlNDM1IDEwMDY0NAotLS0gYS9tZXRhL2Ns YXNzZXMva2VybmVsLmJiY2xhc3MKKysrIGIvbWV0YS9jbGFzc2VzL2tlcm5lbC5iYmNsYXNzCkBA IC0yNDYsNiArMjQ2LDM1IEBAIGtlcm5lbF9kb19pbnN0YWxsKCkgewogCVsgLWUgTW9kdWxlLnN5 bXZlcnMgXSAmJiBpbnN0YWxsIC1tIDA2NDQgTW9kdWxlLnN5bXZlcnMgJHtEfS9ib290L01vZHVs ZS5zeW12ZXJzLSR7S0VSTkVMX1ZFUlNJT059CiAJaW5zdGFsbCAtZCAke0R9JHtzeXNjb25mZGly fS9tb2R1bGVzLWxvYWQuZAogCWluc3RhbGwgLWQgJHtEfSR7c3lzY29uZmRpcn0vbW9kcHJvYmUu ZAorCisJIyBDcmVhdGUgYSBzdWJzZXQgb2Yga2VybmVsIHNvdXJjZXMsIG5lZWRlZCBmb3Igb3V0 LW9mLXRyZWUgbW9kdWxlIGNvbXBpbGF0aW9uLgorCisJa2VybmVsZGlyPSR7RH0vbGliL21vZHVs ZXMvJHtLRVJORUxfVkVSU0lPTn0vYnVpbGQKKwlpbnN0YWxsIC1kICRrZXJuZWxkaXIKKwkjbG4g LXNmICR7S0VSTkVMX1NSQ19QQVRIfSAiJHtEfS9saWIvbW9kdWxlcy8ke0tFUk5FTF9WRVJTSU9O fS9idWlsZCIKKworCWNwIC1hICAke1NUQUdJTkdfS0VSTkVMX0JVSUxERElSfS8uY29uZmlnICRr ZXJuZWxkaXIKKwljcCAtYVIgJHtTVEFHSU5HX0tFUk5FTF9CVUlMRERJUn0vaW5jbHVkZSAka2Vy bmVsZGlyCisJY3AgLWFSICR7U1RBR0lOR19LRVJORUxfQlVJTERESVJ9L2FyY2ggJGtlcm5lbGRp cgorCisJY2QgJHtTfQorCisJcnN5bmMgLWF2bSBcCisJCS0taW5jbHVkZT0iKi8iIFwKKwkJLS1p bmNsdWRlPSJNYWtlZmlsZSoiIFwKKwkJLS1pbmNsdWRlPSJLY29uZmlnKiIgXAorCQktLWluY2x1 ZGU9IktidWlsZCoiIFwKKwkJLS1pbmNsdWRlPSJNb2R1bGUuc3ltdmVycyIgXAorCQktLWluY2x1 ZGU9Ii5jb25maWciIFwKKwkJLS1pbmNsdWRlPSIqLmgiIFwKKwkJLS1leGNsdWRlPSIqIiBcCisJ CS4gJGtlcm5lbGRpcgorCisJcnN5bmMgLWF2bSBcCisJCS0tZXhjbHVkZT0iKi5vIiAgXAorCQkt LWV4Y2x1ZGU9Ii5kZWJ1ZyIgXAorCQkuL3NjcmlwdHMgJGtlcm5lbGRpcgorCiB9CiBkb19pbnN0 YWxsW3ByZWZ1bmNzXSArPSAicGFja2FnZV9nZXRfYXV0b19wciIKIAo=