[OE-core] kernels

[Bruce Ashfield]

On Fri, Jul 15, 2011 at 11:02 AM, Phil Blundell <philb at gnu.org> wrote:
> On Fri, 2011-07-15 at 09:51 -0400, Bruce Ashfield wrote:
>> On Fri, Jul 15, 2011 at 9:21 AM, Phil Blundell <pb at pbcl.net> wrote:
>> > The other day I was working on a BSP layer for a fairly generic i586
>> > system and I was struck by the fact that we don't appear to have any
>> > vanilla kernel recipes in oe-core.  I had sort of expected that, to get
>> > a standard bzImage out, I would just need to ship an appropriate
>> > defconfig in my layer and everything else would "just work".
>>
>> Hmm. Perhaps it isn't documented clearly enough as such, but the linux-yocto
>> kernel base can work in this mode, since that was a design goal of
>> 1.0.
>>
>> You pick a branch, throw in a config fragment (or defconfig if you really
>> want)  and build. The base branches in the tree are generic enough to
>> sort a range of boards out of the box, and should form a base.
>
> Okay, cool.  I'll give it a go and see how I get on.
>
> Is there a description anywhere of what the functional differences are
> between the code in linux-yocto git and the upstream kernel.org tree?

It varies, and the variables are many, so I can answer this in several ways.

Here's some bullet points to save anyone from reading an essay:

 - The ultimate source is obviously the upstream kernel. The goal is
no patches, or
   are the very least, no changes that are carried for a significant
amount of time.
   This typically holds for BSPs, drivers, bug fixes, etc. But sometimes not for
   features or other out of tree projects that haven't made it as
viable upstream
   features (yet .. or ever).

   So all that says is that "We aren't trying to vary it wildly, but
create an infrastructure
   where interesting projects can be tried out, and to allow others to
vary it wildly if they
   want"

 - The linux-yocto tree, once a branch is checked out and a build is
started, is just
    like any other kernel tree. There are plenty of other examples of
trees with multiple
    branches for containing and controlling development. The
difference here could be
    that the branch is found and checked out by the build process
(that's the more
    'complex' mode, but you can just build 'whatever branch the repo
is on' as well)

 - To see the actual differences from the upstream base, there are tags and the
   branches themselves, which all facilitate using git to dump logs
and changes from
   the merge base of the core branches (i.e. yocto/base).

  - The features you'll find in the tree change by kernel version
(since some projects
    may lag their updates and hence miss a tree or two), timing of the mainline
    kernel, the invasiveness of a feature or simply what is being
worked on by some
    yocto (or other) developers!

Hope that helps,

Bruce



>
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"