From: Ulf Samuelsson <ulf.samuelsson@atmel.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH 1/5] Use common files for AT91SAM9 configuration
Date: Mon, 25 Oct 2010 17:35:10 +0200 [thread overview]
Message-ID: <4CC5A3AE.1040509@atmel.com> (raw)
In-Reply-To: <AANLkTi=hLsCrMjw4_mvyniVX8GUsqkVZ2nUnrcm4-UD6@mail.gmail.com>
Frans Meulenbroeks skrev:
> 2010/10/22 Ulf Samuelsson <ulf.samuelsson@atmel.com>:
>> Koen Kooi skrev:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 21-10-10 10:43, Frans Meulenbroeks wrote:
>>>
>>>> PS: my opinion is that machine maintainers generally know better what
>>>> kernel works best for their machines than distro owners;
>>> And what's stopping them to put DEFAULT_PREFERENCE_machine and
>>> COMPATIBLE_MACHINE in the kernel recipes?
>>> There is no technical reason for setting it in machine.conf, so why
>>> should we break the orthogonality for that?
>>>
>>>> PPS: what's next? removing the PREFERRED_PROVIDER_virtual/kernel from
>>>> the machine configs because you feel you know better ?
>>> That is actually an option these days since most kernel recipes set
>>> COMPATIBLE_MACHINE correctly :)
>>> But seriously, there are use cases for one distro to use a different
>>> kernel for a given machine for whatever reasons.
>>>
>>> This whole situation is a mess because recipes/linux is a mess. It would
>>> be a nice topic for OEDEM to see if we should switch to a poky BSP
>>> model. It would boils down to:
>>>
>>> 1 bblayer per machine or SOC_FAMILY containing:
>>> * machine.conf
>>> * first and second stage bootloaders
>>> * kernel
>> I have already come to the conclusion that we could have a single linux.bb
>> recipe.
>>
>> This assumes that you define things like KERNEL_VERSION, SOC_FAMILY
>> etc. outside the recipe and then include files with include filenames
>> containing approproate ENVIRONMENT variables.
>>
>> I.E:
>> include $(KERNEL_VERSION)/kernel_source
>> include $(SOC_FAMILY)/$(KERNEL_VERSION)/kernel_patch
>>
>> etc.
>>
>
> Isn't that what kernel.bbclass is about ?
>
> Wrt your example:
> instead of
> include $(KERNEL_VERSION)/kernel_source
> you could say:
> at the place where you define kernel_source:
> SRC_URI = "..."
>
> Basically what you propose is kind of a template.
>
Didn't study kernel.bbclass.
A problem with this approach, is that different kernel version
are located in different directories.
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.36-rc8.tar.gz
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.36.tar.bz2
If we want to have a single linux.bb file, then it
seems to be cleaner to have an include file per kernel version which
specifies both the directory and the file name.
$(KERNEL_VERSION)/kernel_source would then contain
SRC_URI =
"http://www.kernel.org/pub/linux/kernel/v2.6/linux-$(KERNEL_VERSION).tar.bz2"
for a stable kernel, and
SRC_URI =
"http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-$(KERNEL_VERSION).tar.bz2"
for a release candidate.
One this file is created for a kernel version, it would require little
or no maintenance.
Similar files in the SOC_FAMILY directory structure would control which
minor patch as well as other architecture specific patches to be added.
> Frans
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
next prev parent reply other threads:[~2010-10-25 15:38 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-16 12:50 [PATCH 1/5] Use common files for AT91SAM9 configuration ulf.samuelsson
2010-10-16 12:50 ` [PATCH 2/5] Add AT91SAM9 linux-2.6.30 from www.linux4sam.org ulf.samuelsson
2010-10-16 12:50 ` [PATCH 3/5] Add u-boot-2009.11 support for AT91SAM9 ulf.samuelsson
2010-10-16 12:50 ` [PATCH 4/5] Add X-Windows support for AT91 LCD controller ulf.samuelsson
2010-10-16 12:50 ` [PATCH 5/5] Add X11 images with more multimedia support (mplayer etc.) ulf.samuelsson
2010-10-18 13:18 ` Marcin Juszkiewicz
2010-10-18 13:46 ` Ulf Samuelsson
2010-10-18 13:20 ` [PATCH 1/5] Use common files for AT91SAM9 configuration Marcin Juszkiewicz
2010-10-18 13:38 ` Ulf Samuelsson
2010-10-18 15:36 ` Koen Kooi
2010-10-18 17:00 ` Frans Meulenbroeks
2010-10-18 17:16 ` Ulf Samuelsson
2010-10-18 17:10 ` Ulf Samuelsson
2010-10-18 19:05 ` Khem Raj
2010-10-18 23:10 ` Ulf Samuelsson
2010-10-18 23:33 ` Khem Raj
2010-10-20 23:57 ` Ulf Samuelsson
2010-10-21 6:00 ` Khem Raj
2010-10-25 15:38 ` Ulf Samuelsson
2010-10-25 17:56 ` Khem Raj
2010-10-25 19:32 ` Ulf Samuelsson
2010-10-25 19:39 ` Frans Meulenbroeks
2010-10-28 19:04 ` Ulf Samuelsson
2010-10-21 8:11 ` Koen Kooi
2010-10-21 8:43 ` Frans Meulenbroeks
2010-10-21 9:25 ` Koen Kooi
2010-10-21 9:53 ` Frans Meulenbroeks
2010-10-21 22:01 ` Ulf Samuelsson
2010-10-22 6:28 ` Frans Meulenbroeks
2010-10-25 15:35 ` Ulf Samuelsson [this message]
2010-10-19 2:30 ` Philip Balister
2010-10-19 7:24 ` Frans Meulenbroeks
2010-10-20 23:44 ` 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=4CC5A3AE.1040509@atmel.com \
--to=ulf.samuelsson@atmel.com \
--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.