Yocto, modify kernel sources 'on flight' I'm facing a weird situation. The Linux kernel built within Yocto does not seem to include a certain driver, that I need in order to detect the flash. As a result, the MTD partitions are missing, and the kernel panics, not being able to mount the root filesystem. From the configuration perspective, all seems to be correct. Yet the driver is not there. Besides the fact that the detection fails, I can also tell by running `objdump -t vmlinux | grep -Fe some_symbol_I_know` and noticing that the symbol is not present. While trying to investigate, I'd like to mess quickly with the kernel, e.g. adding some garbage in a module, so that I can see if it is built or not: if it is, the compiler should fail. The slow way of doing it is to push a patch on the repository, so that the code is broken *in git*. Upon compilation, Yocto detects a new commit on the same branch and builds it. This works, but I want to have faster interactions. I've managed to locate the source directory of the kernel, where yocto compiles it (quite an achievement itself, with Yocto creating quite a hierarchy on the filesystem!). Then I littered a piece of code that is definitely compiled, but bitbake did not produce any error. I asked on IRC, where I've been given with a piece of advice. I'll sum up here what I found out. Bitbake does not see the modifications in the source code. It will not re-build it unless it does not detect a change on the *remote* git repo. Messing with the local copy will not cause the binary to be rebuilt, as it does not count as "cache invalidation", so to say. The right thing to do is `devtool modify $recipe`. I recall I've read about it before. The command will place the sources in the "workspace", adding the path of it to the conf/bblayers.conf. Since the order of layers matters, the layer in the workspace will override the actual one. At that point the modifications to the source code will be honoured. devtool help -> list of commands read about: devtool reset devtool finish