Khem Raj skrev: > On Mon, Oct 18, 2010 at 10:10 AM, Ulf Samuelsson > <[email protected]> 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 [email protected] >>>>> 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? 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 [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
