[OE-core] kernels

[Bruce Ashfield]

On Fri, Jul 15, 2011 at 11:36 AM, Bruce Ashfield
<bruce.ashfield at gmail.com> wrote:
> 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.

Following up on my own email. I'm just about to push out the 3.0
kernel support / changes, so I'm seeing the light at the end of the tunnel
and recalled that this is still hanging a bit.

Is there anything tangible you wanted me to do here ?  Create an example ?
Write a short howto  .. or something else ?

Cheers,

Bruce

>
> 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"
>



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