[linux-yocto] looking for doc for in-house linux-kernel dev tree

[Jean-François Dagenais]

Hi all,

I've gone through lots of doc concerning kernel development but couldn't find the right fit.

I like to develop the kernel the old-fashion way, i.e. I have a linux repo clone on my desktop. I have several "remotes" on it, such as torvalds, linux-yocto-3.4, kernel.org's stable and my office's gitlab server's clone. I also try to participate actively in the mainline kernel by submitting work and my workflow is generally organized around this linux git clone.

Locally, I build my kernel manually (without bitbake), using the plain kernel Makefile targets. I deploy modules to a local dir which is NFS exported rootfs made by yocto. The rootfs is rather full of debug stuff too and is useful to support userspace apps development as well. The vmlinuz is deployed on an extlinux USB boot key via ssh if the machine is running or just copied directly otherwise (no initramfs is used). Quite happy with the setup as it allows super quick tweak-don't_commit-compile-run turnaround.

I've made special effort to keep my master branch parallel to the kernel.org's main trunk, e.g. I don't merge v3.2.x into my master. Instead, I merge v3.2 in my master, then create a yocto version specific branch (like denzil or danny) into which I merge my master, standard/crownbay, emgd, and v3.2.x, and later v3.2.x+1, etc. Historically we've maintained a linux-mycompany.bb and a defconfig blob under yocto 1.2 which pointed to this fully final and merged branch I maintain. Made sense, it's simple and allows development to use the exact same branch as yocto builds.

But as we increase the number of machines and image types (debug, release, manufacturing, etc.) we need to support, and want to keep up with yocto releases, while benefiting from upstream improvements, we now want to harness the meta mechanism in linux-yocto so we can more flexibly manage it all.

I see a lot of yocto docs which recommend system integrators to develop or maintain patches... I don't like managing patches. I am good with direct git commits workflow.

As described in manuals, we've copy/pasted the kernel meta branch's crownbay bsp folder and customized it. Initially my reflex was to include the crownbay-standard.scc from my BSP's .scc file instead. This way my bsp would inherit crownbay improvements directly. Unfortunately I haven't found a way to disable kernel CONFIG_* flags which crownbay (or what it includes) explicitely enables. (Thoughts here?) So here we are. In recipe space, we've bbappended linux-yocto-3.4 so we can override the SRC_URI to use our in-office linux kernel git clone (or my development clone) populated with my merged branch and our customized meta branch, as well as provide different sha1's for the "machine" and "meta".

Works as expected... but I am already getting into troubles. It seems the linux-yocto build is not expecting this branch that already contains yocto mods such as kprobes and such: see log on pastebin: http://pastebin.ca/2388697

Are we going in the wrong direction? I wanted to ask early while I keep digging into this. I have to say I was quite surprised to have difficulty finding similar stories... perhaps I am not using the right keywords in google?

Thanks for any pointers!
Regards,
/jfd