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

[Philip Balister <philip@balister.org>]

On 10/18/2010 07:10 PM, Ulf Samuelsson wrote:
> Khem Raj skrev:
>> On Mon, Oct 18, 2010 at 10:10 AM, Ulf Samuelsson
>> <ulf.samuelsson@atmel.com>  wrote:
>>> Koen Kooi skrev:
>>>> On 18-10-10 15:38, Ulf Samuelsson wrote:
>>>>> Marcin Juszkiewicz skrev:
>>>>>> Dnia sobota, 16 pazdziernika 2010 o 14:50:02 ulf.samuelsson@atmel.com
>>>>>> napisaB(a):
>>>>>>
>>>>>>> +++ b/conf/machine/include/at91-2.6.30.inc
>>>>>>> +++ b/conf/machine/include/at91-2.6.32.inc
>>>>>> Do you plan to duplicate that file with each kernel you will produce?
>>>>>> Create include/at91-sam9.inc and put it there.
>>>>>>
>>>>>> Regards,
>>>>> This is to allow different kernel versions for different AT91 chips.
>>>>> This allows both a "stable" version, and a development kernel
>>>>> to be easily handled.
>>>>> The file defines (amongst other things) the
>>>>> * kernel version,
>>>>> * u-boot version
>>>>> * at91bootstrap version
>>>>> so you need one file per version.he
>>>> NAK! Machines don't get to decide versions! Please revert that commit
>>>> and come up with a better way, e.g. default_preference in the recipes or
>>>> distro include files.
>>> If I look at the machine files, almost all of them provide
>>> a preferred kernel / u-boot. Some also provide version.
>>
>> we should avoid pinning versions there. Choosing a type is fine.
>>
>
> Why ?
> Is it because it affect rebuild time?
> It would be good to understand what problems people see with this.
>
> We are pinning the version to a specific machine, in the kernel recipe.
> If we add a new recipe, then we can, by increasing the priority
> force a different kernel to be built.
> This will not affect anything else.
>
> If the version is in the machine configuration, then a change of
> kernel version could force a total rebuild, or?
>
> Any other problem?

In general, if you pin a version in a machine file, consider what 
happens in the case of a distro that supports many machines. Your 
machine build one version of something and the other machines build another.

now do an update, upgrade on a package the version you chose may change, 
or it may change on the other machines. There are likely some packages 
you can pin version in machine files, but in general, it will cause 
problems for distros that support more than just one machine at a time.

Philip


>
> BR
> Ulf Samuelsson
>
>
>
>>> The patch will move the definition from the machine file to the include
>>> file for a few board, so reverting the patch will not solve the problem,
>>> just spread it out into multiple files.
>>> The patch also adds some boards.
>>
>> it pins a kernel version thats not ok IMO. You should pin this in the
>> kernel recipes
>> instead for the machines that should use it using PREFERRED_VERSIONS
>>
>>> Having default preference in recipes is not going to make it easy to
>>> switch between version so I don't like that method at all.
>>>
>>
>> what do you mean by easy here ? Its not difficult to change two
>> priority numbers. I think we should try to remain inline with our
>> policies
>> whatever they are otherwise it will create confusion.
>>
>>> Using the distro to select boot and kernel, seems flawed since none of
>>> the stuff will reside in the file system (my file system)
>>> but at least this is easily maintainable.
>>>
>>
>> usually in OE distros set policy with sufficient knowledge of machine
>> characteristics
>> you can think of ways to use this approach. distro does not decide on
>> which kernel or u-boot
>> these are machine specific recipes and you decide which one to feed
>> for which machine in the recipe.
>>
>>> The best right now seems to be to make a new distro file for each kernel
>>> version, which just includes Angstrom and adds version info for kernel,
>>> u-boot and at91bootstrap.
>>>
>>> Long term, I think that there should be something equivalent to DISTRO
>>> for the files outside the file system, and that you should be able to
>>> select between multiple variants like you select a DISTRO today,
>>> but I am not yet into bitbake, so I can't tell where to start.
>>>
>>> Since the reversal of the patch, wont solve anything,
>>> I suggest we agree on how to proceed, and then do the fixes.
>>> Is including Angstrom from a kernel specific distro file OK?
>>
>>
>>
>>> If a distro file is to include another file, then
>>> you have to be able to tell different kernels for
>>>
>>>
>>> I guess we could do:
>>>
>>> require   conf/distro/include/$(SOC_FAMILY).inc
>>>
>>> conf/distro/include/at91.inc would contain:
>>>
>>>
>>> PREFERRED_VERSION_at91bootstrap = "2.13"
>>> PREFERRED_VERSION_u-boot = "2009.11"
>>
>> why is all this needed ?
>>
>>> Not sure how to do machine dependent kernel version
>>>
>>> PREFERRED_VERSION_linux_at91sam9g45ek = "2.6.30"
>>> does not feel like it would work.
>>> Ideas?
>>>
>>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>