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

[Bruce Ashfield]

On 13-06-03 10:29 PM, Jean-François Dagenais wrote:
> Hi all,
>
> I've gone through lots of doc concerning kernel development but couldn't find the right fit.

Are you working on the yocto master branches ? I ask, because there are
different features in different branches of the project.

>
> 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.

Completely reasonable, and exactly what I do as well.

>
> 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.

Also reasonable, and something I use as well.

>
> 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.
>

This is the right thing to do .. in my opinion anyway!

> 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".

If you look at poky-extra/meta-kernel-dev, you'll see that the approach
of pointing to a different repo is common, and supported. I do something
very similar for other kernel trees that I maintain, including overriding
and changing all sorts of configs.

So that matches your first reaction and something that I've been
using for quite some time.

If you apply .cfg fragments in an iherited BSP that disable options
in the base BSP (via # CONFIG_FOO is not set), you will be able to
turn them off, you of course have to know what the BSP is setting, but
if you are deriving work from a board, that's a reasonable thing to do.
If you've tied this, and it isn't working, that's a bug.

There are some other options you can use as well, but I'd rather talk
about option #1 for now.

>
> 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
>

Correct. All of the base branches would already contain those
modifications, so you can't trigger then again, unless you are
really starting from scratch. If the tools can't determine that
a patch is present, it will try to reapply it with the sort of
errors that you are seeing if it really does exist.

What does your BSP's .scc file look like ? Is it something you
can share ?

> 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?
>

I've got some READMEs on this, but they are not useful by themselves.
I'd like to use your use case (which is valid and useful), to clean them
up and publish them for the 1.5 release. Perhaps we can even find some
gaps in the tools and improve things in the process .. assuming you have
the will to work through the case with me!

Cheers,

Bruce

> Thanks for any pointers!
> Regards,
> /jfd
>
>
>
>
>
>
> _______________________________________________
> linux-yocto mailing list
> linux-yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto
>