11441 2017-05-03 08:05:36 +0000 archiver.bbclass should not cause kernel rebuilds 2017-06-22 08:14:59 +0000 1 1 7 Build System, Metadata & Runtime OE-Core deployment unspecified x86 Multiple RESOLVED FIXED Medium enhancement 2.4 1 patrick.ohly patrick.ohly mikko.ylinen richard.purdie --- --- No (bug/feature does not impact docs) oldest_to_newest 72987 0 patrick.ohly 2017-05-03 08:05:36 +0000 When building a kernel-yocto based kernel with INHERIT += "archiver" in local.conf and then without, the kernel gets rebuilt (i.e. do_kernel_configme, do_compile, etc. run again). This shouldn't happen because do_kernel_configme will do the exact same thing in both cases, as it doesn't depend on the archiver. The root cause is this special code in archiver.bclass: python () { # Add tasks in the correct order, specifically for linux-yocto to avoid race condition if bb.data.inherits_class('kernel-yocto', d): bb.build.addtask('do_kernel_configme', 'do_configure', 'do_unpack_and_patch', d) } It leads to a sstate signature difference: $ bitbake-diffsigs 4.9.15+gitAUTOINC+b65e9b6153_6f425e57c6-r0.do_kernel_configme.sigdata.a8d09670469a0547a5e67c51254e05f4 4.9.15+gitAUTOINC+b65e9b6153_6f425e57c6-r0.do_kernel_configme.sigdata.1b4e707e7808e7e5943cbc5a07f76957 runtaskdeps changed: ['linux/linux-intel_4.9.bb.do_patch', -linux/linux-intel_4.9.bb.do_unpack_and_patch] Number of task dependencies changed Dependency on task linux/linux-intel_4.9.bb.do_unpack_and_patch was removed with hash dd65da57cbdac87149c486bc932263d5 72988 1 patrick.ohly 2017-05-03 08:14:23 +0000 Personally I think that this can only be solved by defining a new "weak dependency" that defines that "if task A is active, it needs to run before task B" without the current semantic that "task B depends on output from task A and thus needs to be re-run when adding/removing/changing task A". Such a weak dependency would also help solving some of the issues with do_rm_work. 72989 2 richard.purdie 2017-05-03 08:24:42 +0000 Adding something to the signature code which allowed it to ignore the dependency from a task signature perspective would probably be comparatively straightforward and allow you to solve the rebuild issue. Note that running the class would still cause the source to be extracted and archived since there is now way to avoid that in order for this task to do its work. Note that this dependency is technically correct, do_kernel_configme changes ${S} and hence really *must* run after do_unpack_and_patch. Calling this a weak dependency is therefore misleading, there is very much a hard ordering constraint, the issue is more that the task doesn't affect the data and therefore the other tasks can be reused from sstate safely. I do also worry that the semantics of this particular issue may not be 100% the same as the weak task ordering issues that rm_work has. There may certainly be similarities but experience in this code says the bar to adding new tasks has to be extremely high and we'd have to have a much more specific definition of how this new task type would have to work before we'd consider doing that. The code in this area is already complex and potentially problematic so adding changes here for comparatively minor use cases has to be approached with caution. So my question comes back to whether we really need a way to whitelist a task dependency from the sstate hash instead? 73056 3 richard.purdie 2017-05-04 15:58:03 +0000 In sstatesig.py:sstate_rundepfilter(), I think you could add something like: if dataCache and isKernel(depfn) and isKernel(fn) and task == "do_patch" and dep.endswith(".do_unpack_and_patch"): return False Unfortunately it would have to go right at the top of the function since: # Always include our own inter-task dependencies if recipename == depname: return True would otherwise trigger. 74455 4 patrick.ohly 2017-06-22 08:14:59 +0000 Merged, fed0ed82928e6a7846fbad233ac657bd17bcefc7 "archiver.bbclass: do not cause kernel rebuilds"