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

Jean-François Dagenais jeff.dagenais at gmail.com
Wed Jun 12 08:27:24 PDT 2013

Hi Bruce, thanks for the answers!

On 2013-06-10, at 1:04 AM, Bruce Ashfield wrote:

> [...]
>> Couple of questions:
>> - What exactly does AUTOREV do?
> The fetcher always gets the latest commit on the branches. During
> development, we want to pick up everything that is pushed, without
> needing to tweak all the SRCREVs.
>> - Is it possible to get this bbappend to use the current working directory state (including un-committed changes)
>>   using the SRC_URI and AUTOREV?
> The SRCREV will only control what the fetcher pulls in, and then
> what is checked out. The compile phase will then start. If there
> are patches, or other touches to files that aren't committed, they
> will be built. But if you have uncommitted changes, you'll have
> potential issues with branch switches, etc.

You mean if I make changes in the non-bare repo clone found in
tmp/work/.../linux-yoctoXYZ/linux after the bitbake build has set it up?

>> - what is the _pn_ and why is it absent in the poky-contrib example? (SRCREV_machine_${MACHINE}="${AUTOREV}" and
>>   SRCREV_meta="${AUTOREV}")
> A bitbake OVERRIDE value. _pn_ "package name". You'll find other
> examples floating around the tree, and various layers.

I have found other examples yes, still don't know what it overrides, and why the
linux-yocto_3.x.bbappends use that, but the poky-contrib
linux-yocto_3.x.bbappends don't.

>> - in SRC_URI what does the nocheckout=1 and bareclone=[0-1] do? I've had error reports about this in
>>   tmp/work/machine/linux-yoctoXYZ/temp logs.
> The tools work on the branches, to quickly make a copy of the tree
> that has all the branches local, a bareclone and checkout in the
> build directory is done. That is what those options control.

Right... Found the most detailed doc I could at:
poky/bitbake/lib/bb/fetch2/git.py Is the term bareclone the same as in git
terminology? I.e. a bare clone is just the .git directory, no files are checked
out of the git DB. I could not detect any difference between "bareclone=1" and
"nocheckout=1", nor could I find any "git bare clones" in tmp/work. The
downloads directory contains a true "git bare clone" of the repo mentioned in
SRC_URI in either cases (nocheckout=1 or bareclone=1). Still a bit fuzzy, I am
gathering that this is more of an optimization than anything perhaps?

>> [...]
>> We did some more experiments and found a lot of confusion around recipe-space's
>> "KBRANCH_osprey = x" vs. meta-space's "branch osprey" statements. I have
>> observed that if in my gitlab repo, I create a branch called "standard/osprey"
>> and this branch is a merge of my-master + emgd-1.16 + standard/crownbay, the
>> recipe build tries to patch things like kprobes and such, and basically fails
>> saying:
>> | ERROR: branch standard/osprey was requested, but was not properly
>> |        configured to be built. The current branch is standard/osprey/base
>> 'standard/osprey/base' has not be mentionned anywhere that I can see, it's a
>> product of the recipe's work.
> It's a property of there being a subbranch of "standard/osprey" being
> detected. Due to the way that git stores refs on disk, we have to
> rename "standard/osprey" to standard/osprey/base if something like
> standard/osprey/bsp is being requested.

>> If I don't prefix with "standard/" in KBRANCH, then it doesn't patch and things
>> seems to work correctly.  (BTW, my gitlab is a clone of your linux-yocto-3.4, we
>> just add new branches to that)
>> Is this behaviour normal? If so, is there documentation for this? Another detail
>> when I had the prefix "standard/" in my setup: I have temporarily tried to set
>> branch "standard/base" at the same sha1 as my standard/osprey branch, that made
>> no difference.
> It is normal, and just the tools trying to help you out. The docs
> may be slim in this area, I'll double check tomorrow.
>>> What does your BSP's .scc file look like ? Is it something you
>>> can share ?
>> bsp/osprey/osprey.scc:
>> define KMACHINE osprey
>> define KTYPE standard
>> define KARCH i386
>> include ktypes/standard/standard.scc
>> branch osprey
>> kconf hardware bsp/common-sonatest/hardware.cfg
>> kconf hardware bsp/common-sonatest/w1.cfg
>> kconf hardware osprey.cfg
>> kconf non-hardware bsp/common-sonatest/non-hardware.cfg
>> include cfg/x86.scc
>> include features/irq/irq.scc
>> include features/intel-e1xxxx/intel-e100.scc
>> include features/intel-e1xxxx/intel-e1xxxx.scc
>> include cfg/dmaengine.scc
>> include cfg/8250.scc
>> include features/power/intel.scc
>> include features/usb/ehci-hcd.scc
>> include features/usb/ohci-hcd.scc
>> include features/aufs/aufs.scc
>> include features/drm-emgd/drm-emgd-1.16.scc
>> # default policy for standard kernels
>> include cfg/usb-mass-storage.scc
>> include cfg/boot-live.scc
>> include features/latencytop/latencytop.scc
>> include features/profiling/profiling.scc
>> aufs.scc looks like:
>> kconf non-hardware aufs.cfg
>> branch aufs
>> and branch aufs exists in my linux clone. It's a merge of upstream-aufs-3.4 +
>> v3.4.46 + standard/base. The resulting aufs branch is merged into my machine
>> branch in my clone.
> aha. And that's what is triggering the problem. Without extra
> instructions, branch names are "additive", that's how the hierarchy
> gets built up without encoding the names all over the .scc files.
> So that "branch aufs" means, create:
>  standard/osprey/aufs
> .. and hence what I described above must come true.
> So you are looking for aufs, just like i have in the 3.8 tree already?
> In that case, what you can do is simply create that branch and merge
> your changes. i.e. without describing the branch in the .scc file.

You mean make my aufs.scc a one-liner that's just "kconf non-hardware aufs.cfg"?
But what about the other scc's that we include? if they mention feature names in
using the scc "branch" statement, won't the tooling look for
standard/osprey/featureX which doesn't exist but its code is already merged in
the machine branch we mentioned in KBRANCH?

> If you've already merged it into your BSP branch, no need to merge
> it again, but you could just make the aufs.scc be:
>  git merge aufs
Sorry, maybe just a typo, but since I am a bit confused about all this, let's
make sure: you said if I DON'T need to merge it again? If so, wouldn't the "git
merge aufs" in aufs.scc tell the kernel tools to make git merge aufs... which is
already merged in my machine branch? I guess I don't understand what the scc
"branch xyz" vs. "git merge xyz" statements mean or do.

> And your BSP will merge the changes into it's branch on each build.

In the end though, for this scenario to work as expected, we would need to have
all the intelligent patching and merging completely disabled, while keeping the
config fragment parts still working. While we seem to have stumbled on aWhat
combination of flags, branch names and variable names should we use/avoid to
obtain this desired behaviour?

Thanks for your patience and help. I hope others will benefit from our pains!

More information about the linux-yocto mailing list