All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted.
Date: Thu, 13 Aug 2009 09:12:40 +0200	[thread overview]
Message-ID: <h60eda$re1$1@ger.gmane.org> (raw)
In-Reply-To: <4A833D9F.1090608@atmel.com>

On 13-08-09 00:09, Ulf Samuelsson wrote:
> Phil Blundell skrev:
>> On Wed, 2009-08-12 at 14:33 +0200, Marcin Juszkiewicz wrote:
>>> Dnia wtorek, 11 sierpnia 2009 o 20:55:00 Ulf Samuelsson napisał(a):
>>>> I introduced the possibility to build linux using
>>>> make<board>_defconfig, instead of using a
>>>> defconfig in a board directory under linux.
>>>> LINUX26_DEFCONFIG needs to be defined.
>>> Interesting, will check. I see a problem anyway because linux_*.bb
>>> recipes by default use defconfig as part of SRC_URI. But we can use
>>> empty file to satisfy it.
>>
>> We've tried this kind of thing before on various platforms and it
>> generally seems to be a losing proposition.  Even if your kernel sources
>> are targetting just a single MACHINE, the kernel isn't quite modular
>> enough yet that you can truly have a "one size fits all" configuration
>> to suit all DISTROs.
>>
>> Also, if you are relying on the defconfig from upstream, any
>> configuration change at all requires that you either patch it, or
>> re-issue the upstream tarball.  Neither of those are as convenient as
>> just editing the defconfig locally in OE.
>>
>> So, in general, I think you're probably better off sticking with the
>> "defconfig in FILESDIR" paradigm.  That's not to say I'm completely
>> opposed to adding the option to use the one from upstream, but I think
>> you would need to be a bit careful about where you use it.
>>
>> p.
>
> Initially, this is to allow easy test of a new board where a config
> exists in the kernel.

You're saying that a 'cp /path/to/source/linux/arch/arm/configs/foo 
/OE/org.oe.dev/recipes/linux/linux/foo/defconfig' is too hard?

regards,

Koen




  reply	other threads:[~2009-08-13  7:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-11 18:55 Contents of the "origin/ulf/linux-2.6.30.2" branch. Help with testing wanted Ulf Samuelsson
2009-08-12 12:33 ` Marcin Juszkiewicz
2009-08-12 13:32   ` Ulf Samuelsson
2009-08-21 11:53     ` Marcin Juszkiewicz
2009-08-22  7:41       ` Ulf Samuelsson
2009-08-23 10:55         ` Marcin Juszkiewicz
2009-08-22 17:45       ` Ulf Samuelsson
2009-08-23 10:41         ` Marcin Juszkiewicz
2009-08-23 11:31           ` Ulf Samuelsson
2009-08-12 15:13   ` Koen Kooi
2009-08-12 15:56   ` Phil Blundell
2009-08-12 22:09     ` Ulf Samuelsson
2009-08-13  7:12       ` Koen Kooi [this message]
2009-08-13  7:10     ` Ulf Samuelsson
2009-08-13 17:34       ` Contents of the "origin/ulf/linux-2.6.30.2" branch. Status update Ulf Samuelsson

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='h60eda$re1$1@ger.gmane.org' \
    --to=k.kooi@student.utwente.nl \
    --cc=openembedded-devel@lists.openembedded.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.