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, three machines, and common
as mydir
, the branches in your
Git repository might look like this:
mydir/base mydir/standard/base mydir/standard/machine_a mydir/standard/machine_b mydir/standard/machine_c mydir/small/base mydir/small/machine_a
This organization can help clarify the branch relationships.
In this case, mydir/standard/machine_a
includes everything in mydir/base
and
mydir/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.
mydir/standard
and
mydir/standard/machine_a
because it
would have to create a file and a directory named "standard".