On 13-07-31 12:07 PM, Andreas Schultz wrote:
Hi,

----- Original Message -----
On 13-07-31 10:46 AM, Andreas Schultz wrote:
Hi,

I've managed to rebuild a complete yocto linux kernel git tree from
the kernel-cache.

Good to hear.


But how do move forward from here with upgrades?

Lets assume my kernel tree was based on 3.8.1 and want to import 3.8.2.
It looks like on the yocto-linux tree a pull from upstream was made and
then a pull from every single branch was made. This is a lot of work,
is there a tool that helps or a different way to update all branches?

The maintenance path issue was caused by your first statement. Building
the complete tree from the kernel-cache. That's something that I typically
only do when cleaning history, dropping features and jumping major
kernel revisions.

But I want (or rather unfortunately need) to maintain my own tree. So how

Understood, and I'm not arguing here, but I just wanted to point out
that maintaining your own tree can obviously be done without generating
that tree from the kernel-cache.

Unless you are dropping large parts, of the patches, etc.

do you carry out those maintenance tasks?

I fetch, validate and then merge to all branches once I'm happy with
the same content on standard/base, I then move to standard/preempt-rt/base, and repeat. That's the goal of someone tracking linux-yocto in
a fast forward manner. You can inherit that testing directly, versus
redoing the same work.

Any new changes, merge fixups, etc, are all made in the tree and then
committed to the kernel-cache, which tracks the history of the work.

In the end, it comes down to standard git maintenance and management
for the most part, with the backing of the permanent history and
the ability to regenerate and clean history at will.


If you are working with an existing version, starting with a clone of
the linux-yocto-3.8 tree is the right thing to do. That way, when I
track and update the -stable updates, or merge other features, you can
simply fetch and merge the changes into your tracking tree.


Also, when I add new fragments to kernel-cache, how are they included
into the yocto-tree? Is there a tool or just a lot of manual merging?

Do you mean the upstream tree ? If so, send them to the linux-yocto
mailing list, where we can review and merge them, which means they'll
be carried forward to any new tree that I generate and available to
all users of the tree.

Most of the changes are for machines that are not in yocto (mostly
MIPS CPE's taken from OpenWRT), some others are for some obscure hardware
that we would like to keep in separate BSP's but provide a single source
tree to our users.

Reasonable requirements. If you aren't actually changing the base patches
and changes, you can easily segment and maintain the BSPs in their
own branches. But again, that's a different maintenance model than
the one you are currently looking for.


If you are talking about your own tree, simply add them to the meta
branch, in the "meta/cfg/kernel-cache/" directory structure, commit
them, and update your SRCREV_meta and they are available.

Ahh, I see and I thought I had to run them through the scc script first.

Only later, if you regenerate the tree.

Bruce


Cheers,

Andreas


Cheers,

Bruce


Regards
Andreas


_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto





_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Reply via email to