On 10/25/10, Ulf Samuelsson <[email protected]> wrote: > Khem Raj skrev: >> On Wed, Oct 20, 2010 at 4:57 PM, Ulf Samuelsson >> <[email protected]> wrote: >>> Khem Raj skrev: >>>> On Mon, Oct 18, 2010 at 4:10 PM, Ulf Samuelsson >>>> <[email protected]> wrote: >>>>> 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. >>>> Well we have distro which sets policies including which recipe >>>> versions to be pinned >>>> machine configuration decides on various machine features. There are >>>> different ways to do it >>>> but if we remain consistent in what we do, we can make it more >>>> understandable for others >>>> >>>> If you feel strongly that your approach is good I think it should be >>>> decided if this is suitable >>>> for majority of OE distro and machines, If it has technical merits >>>> over existing approaches >>>> people will be interested in it. >>>> >>>>> 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? >>>>> >>>> I dont think it will force any rebuild or anything. It will just not >>>> be the way other machines >>>> do things. The machine configuration tend to be version agnostic as >>>> per current approach. >>>> >>>>> Any other problem? >>>>> >>>> what are the issues that you see in following approaches suggested in >>>> this thread so far ? >>> 1) Many boards do put kernel version in the machine conf file. >>> The patch was created to collect common stuff in an include file >>> to make maintenance easier. >>> >>> 2) I cannot assume that all Atmel chips should use the same kernel, >>> so a single include file will not make it. >>> >>> 3) I want to be able to work with two kernel versions for the same chip. >>> This is to have one stable kernel, and one development kernel. >>> The use of the develoment kernel, should not make the stable version >>> unbuildable. >> >> you want to ship with two kernel or you want to work with two kernel >> versions? >> if you just want to develop then you can have the stable kernel >> version as preferred version >> and override that in local.conf with yout dev kernel for development >> purposes. Once you are >> done with it and it is your next stable just add >> DEFAULT_PREFERENCE_<machine> = "1" in that recipe >> and it should become new default for this machine. >> > > I would like to ship with two kernels. > one "stable" kernel, and another "development" kernel > which is accessible to others to allow shared responsibility > for testing purposes. >
you can either use different version of different recipe name with different name you can just override the virtual/kernel PREFERRED_PROVIDER_virtual/kernel = "/whatever/" > Preferably, it should be possible to build both, > without having to rebuild the complete root fs. > yes why not. One just needs to flip the PREFERRED_VERSION in local.conf file and he should not get the kernel version he chose. and no rebuild of rfs is needed. > > >> >> for release you can create your own pinned config file and call it >> inside distro config you have >> and have two distros one for dev and one for stable >>> If I put the preferred version in the recipe, then I can only work >>> with one kernel. >>> >>> If I try to use the preferred version in the recipe, then I >>> have to have two machine files. >>> I.E: >>> at91sam9g45ek >>> at91sam9g45ek-devel >>> >>> and I have to support both machines in the recipe. >>> >>> Once I have come to a point, where the development kernel is >>> to become the stable version, then I have to edit the recipe >>> again to make this the official. >>> I have to remove all references to "sam9g45ek", >>> then I have to modify the "sam9g45ek-devel" settings to refer to >>> "sam9g45ek", remove the sam9g45ek.conf and rename the >>> sam9g45ek-devel.conf to sam9g45ek.conf. >>> >>> I then have to retest everything! >>> >>> As I see it, the kernel/u-boot/at91bootstrap hangs together, >>> and it is easier to maintain a single include file with versions >>> for this, than to maintain the three recipes. >>> >>> If I maintain in the recipes, I have to create a lot >>> of preferred_version_<machine>) in multiple kernel recipes, >>> and with my method, I include a single file in the machine >>> configuration. >>> If I want to change kernel version, I edit a few characters. >>> >>> 4. This points to another weakness. >>> You can only build a certain machine in one way. >>> >>> Today, when we specify a MACHINE, we use "$MACHINE.conf" >>> >>> It would be better, if you could have several machine configuration >>> files referring to the same MACHINE, and specifying the MACHINE >>> in the configuration file. >>> >>> local.conf would then contain >>> >>> MACHINE_CONFIG = at91sam9g45ek-2.6.30.conf >>> >>> "at91sam9g45ek-2.6.30.conf" would contain >>> >>> MACHINE = at91sam9g45ek >>> >>> This would allow several configuration files referring to the same >>> machine. >>> The machine configuration must support selecting separate >>> * linux ".config" >>> * uboot configuration >>> * boot monitor configuration. >> >> why not use existing MACHINE_FEATURES to steer the features you would >> like to change in .config files. >> >> >>> Possibly, then machine configuration should support downloading such >>> stuff from internet. >>> >>> (I don't expect the mainline OE to contain more than one "stable" >>> version) >>> >>> > > BR > Ulf > > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > -- -Khem _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
