[oe] [PATCH 1/5] Use common files for AT91SAM9 configuration

[Frans Meulenbroeks]

2010/10/22 Ulf Samuelsson <ulf.samuelsson at 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.

Frans