From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Leon Woestenberg <leon.woestenberg@gmail.com>
Cc: yocto@yoctoproject.org
Subject: Re: [PATCH] meta-bsp-kirkwood: created layer for Marvellkirkwood
Date: Tue, 24 May 2011 16:38:06 -0400 [thread overview]
Message-ID: <4DDC172E.1010602@windriver.com> (raw)
In-Reply-To: <BANLkTi=7KeMRTkQ7hsp0jXVJNTGfDCAYqQ@mail.gmail.com>
On 11-05-20 11:07 AM, Leon Woestenberg wrote:
> Hello,
>
> On Mon, Nov 29, 2010 at 9:05 PM, Bruce Ashfield
> <bruce.ashfield@windriver.com> wrote:
>> In message: [yocto] [PATCH] meta-bsp-kirkwood: created layer for Marvellkirkwood
>> on 28/11/2010 Frans Meulenbroeks wrote:
>>
>>> This layer is a first attempt to create a layer for kirkwoord.
>>
>> On this topic. Is there any reason to not use linux-yocto
>> for the kernel ? Whenever possible, I'd like to get everyone
>> pulling in the same direction for these platforms. We have
>> ...
>> It also helps us review and push for platforms to be merged
>> upstrea if things go into a common kernel repository.
>> ...
>> It would also mean that the BSP would be kept up to date with
>> bug/security fixes and be considered for updating to
>> ...
>> at these patches in a 2.6.37 context (but obviously I don't
>> have the hardware to use for boot testing).
>>
> These are good points, but we have experienced *lots* of (old) vendor
> kernel patch dumps when I new machine is released.
>
> Surely most patches would not be accepted upstream, or have become
> obsolete (need only much forward porting work in the most ideal case).
>
> In OpenEmbedded, the linux/ directory is wildly populated for this
> practical reason.
>
> How are we going to shove every machine from OpenEmbedded linux/ into
> linux-yocto?
That's not the current plan, but it is of course possible
with enough effort (Where the effort is the obvious: updating
the patches to match the linux yocto targeted version).
>
> Or, better: who decides when it matches linux-yocto or should be
> linux-something else?
I know that I'd consider/help with any reasonable set of patches.
There really aren't any onerous set of requirements. We can build
BSPs out of common branches, share configs, etc, make things
easier for getting a BSP in the tree. Once in there, any
fixes or updates would automatically prop to the BSP. Getting
more boards buildable and supported only helps make things
better.
But there's a catch (isn't there always). Being willing to help
maintain the BSP if a feature merge or conflict occurs. And, if
possible, help look into mainlining the patches. But collecting
up the many vendor patches and sharing what's worth sharing,
moving the towards mainline is a pretty decent initial goal.
There's other options as well. The linux-yocto recipe will
build BSPs that are branched in remote repositories. Those
repos can be kept up to date with common features and fixes
as well.
>
> It's mainly a problem originated by vendors working for years on their
> port and then dumping their 2.6.32 kernel in 2.6.39 times, not blaming
> anyone else here :)
Absolutely. I'm in the same situation on a daily basis.
Cheers,
Bruce
>
> Regards,
prev parent reply other threads:[~2011-05-24 20:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-28 20:00 [PATCH] meta-bsp-kirkwood: created layer for Marvell kirkwood Frans Meulenbroeks
2010-11-29 20:05 ` [PATCH] meta-bsp-kirkwood: created layer for Marvellkirkwood Bruce Ashfield
[not found] ` <AANLkTimm0MxsA4M9eMaPs9jd8-MKB5z9F7kQ714L8umK@mail.gmail.com>
[not found] ` <4CF40E3B.10202@windriver.com>
2010-11-29 21:07 ` Frans Meulenbroeks
2010-12-02 15:55 ` Darren Hart
2011-05-20 15:07 ` Leon Woestenberg
2011-05-24 20:38 ` Bruce Ashfield [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DDC172E.1010602@windriver.com \
--to=bruce.ashfield@windriver.com \
--cc=leon.woestenberg@gmail.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.