When you have multiple machines and architectures to support, or you are actively working on board support, it is more efficient to create branches in the repository based on individual machines. Having machine branches allows common source to remain in the "master" branch with any features specific to a machine stored in the appropriate machine branch. This organization method frees you from continually reintegrating your patches into a feature.
Once you have a new branch, you can set up your kernel Metadata
to use the branch a couple different ways.
In the recipe, you can specify the new branch as the
KBRANCH
to use for the board as
follows:
KBRANCH = "mynewbranch"
Another method is to use the branch
command
in the BSP description:
mybsp.scc: define KMACHINE mybsp define KTYPE standard define KARCH i386 include standard.scc branch mynewbranch include mybsp-hw.scc
If you find yourself with numerous branches, you might consider using a hierarchical branching system similar to what the linux-yocto Linux kernel repositories use:
<common>/<kernel_type>/<machine>
If you had two kernel types, "standard" and "small" for instance, and three machines, the branches in your Git repository might look like this:
common/base common/standard/base common/standard/machine_a common/standard/machine_b common/standard/machine_c common/small/base common/small/machine_a
This organization can help clarify the branch relationships.
In this case, common/standard/machine_a
includes everything in common/base
and
common/standard/base
.
The "standard" and "small" branches add sources specific to those
kernel types that for whatever reason are not appropriate for the
other branches.
common/standard
and
common/standard/machine_a
because it
would have to create a file and a directory named "standard".