From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id B1E61E0044D for ; Tue, 13 Mar 2012 21:05:55 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 13 Mar 2012 21:05:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="118602276" Received: from unknown (HELO envy.home) ([10.255.15.199]) by azsmga001.ch.intel.com with ESMTP; 13 Mar 2012 21:05:53 -0700 Message-ID: <4F6018F5.5060302@linux.intel.com> Date: Tue, 13 Mar 2012 21:05:09 -0700 From: Darren Hart User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: Bruce Ashfield References: <86eeec9f1963b57809b988e148ddf43562e2f0bc.1331610171.git.tom.zanussi@intel.com> <4F5FA04C.7080901@linux.intel.com> <1331667871.21321.12.camel@elmorro> <1331694223.21321.21.camel@elmorro> <4F600BAC.5030107@windriver.com> In-Reply-To: <4F600BAC.5030107@windriver.com> X-Enigmail-Version: 1.3.5 Cc: yocto@yoctoproject.org Subject: Re: [PATCH 1/2] meta-crownbay: switch to linux-yocto-3.2 kernel X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 04:05:56 -0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/13/2012 08:08 PM, Bruce Ashfield wrote: > On 12-03-13 11:03 PM, Tom Zanussi wrote: >> On Tue, 2012-03-13 at 22:40 -0400, Bruce Ashfield wrote: >>> On Tue, Mar 13, 2012 at 3:44 PM, Tom Zanussi wrote: >>>> On Tue, 2012-03-13 at 12:30 -0700, Darren Hart wrote: >>>>> Hi Tom, >>>>> >>>>> Some thoughts on this with respect to cleaning up and simplifying the >>>>> recipes per our earlier discussions. >>>>> >>>>> On 03/12/2012 09:37 PM, tom.zanussi@intel.com wrote: >>>>>> From: Tom Zanussi >>>>>> >>>>>> Switch crownbay and crownbay-noemgd to the 3.2 kernel. >>>>>> >>>>>> Signed-off-by: Tom Zanussi >>>>>> --- >>>>>> meta-crownbay/conf/machine/crownbay-noemgd.conf | 2 ++ >>>>>> meta-crownbay/conf/machine/crownbay.conf | 2 ++ >>>>>> .../linux/linux-yocto-rt_3.2.bbappend | 20 ++++++++++++++++++++ >>>>>> .../recipes-kernel/linux/linux-yocto_3.2.bbappend | 17 +++++++++++++++++ >>>>>> 4 files changed, 41 insertions(+), 0 deletions(-) >>>>>> create mode 100644 meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend >>>>>> create mode 100644 meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend >>>>>> >>>>>> diff --git a/meta-crownbay/conf/machine/crownbay-noemgd.conf b/meta-crownbay/conf/machine/crownbay-noemgd.conf >>>>>> index 2c80bd8..af85b00 100644 >>>>>> --- a/meta-crownbay/conf/machine/crownbay-noemgd.conf >>>>>> +++ b/meta-crownbay/conf/machine/crownbay-noemgd.conf >>>>>> @@ -4,6 +4,8 @@ >>>>>> #@DESCRIPTION: Machine configuration for Crown Bay systems, without Intel-proprietary graphics bits >>>>>> # i.e. E660 + EG20T >>>>>> >>>>>> +PREFERRED_VERSION_linux-yocto ?= "3.2%" >>>>>> + >>>>>> require conf/machine/include/tune-atom.inc >>>>>> require conf/machine/include/ia32-base.inc >>>>>> >>>>>> diff --git a/meta-crownbay/conf/machine/crownbay.conf b/meta-crownbay/conf/machine/crownbay.conf >>>>>> index 2c1ef3d..1458bff 100644 >>>>>> --- a/meta-crownbay/conf/machine/crownbay.conf >>>>>> +++ b/meta-crownbay/conf/machine/crownbay.conf >>>>>> @@ -4,6 +4,8 @@ >>>>>> #@DESCRIPTION: Machine configuration for Crown Bay systems >>>>>> # i.e. E660 + EG20T >>>>>> >>>>>> +PREFERRED_VERSION_linux-yocto ?= "3.2%" >>>>>> + >>>>>> require conf/machine/include/tune-atom.inc >>>>>> require conf/machine/include/ia32-base.inc >>>>>> >>>>>> diff --git a/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend b/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend >>>>>> new file mode 100644 >>>>>> index 0000000..dee9bce >>>>>> --- /dev/null >>>>>> +++ b/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend >>>>>> @@ -0,0 +1,20 @@ >>>>>> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" >>>>>> + >>>>>> +COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd" >>>>>> +KMACHINE_crownbay-noemgd = "crownbay" >>>>>> + >>>>>> +KERNEL_FEATURES_append_crownbay-noemgd += " cfg/smp.scc" >>>>> >>>>> I think we start putting cfg/smp.scc in the BSP scc file directly rather >>>>> than in the recipe itself. This can be a follow-on patch, or just with >>>>> the next kernel release even. But I wanted to point it out. >>>>> >>>> >>>> Yeah, I saw that and agree - I just don't want to spend the time to do >>>> all that now. I basically have this week to get them all moved over >>>> into a basically functional state and will submit patches to do this and >>>> the below as follow-ons once the basics are out of the way. >>>> >>>>>> + >>>>>> +COMPATIBLE_MACHINE_crownbay = "crownbay" >>>>>> +KMACHINE_crownbay = "crownbay" >>>>>> + >>>>>> +KERNEL_FEATURES_append_crownbay += " cfg/smp.scc" >>>>>> + >>>>>> +# Update the following to use a different BSP branch or meta SRCREV >>>>>> +#KBRANCH_crownbay-noemgd = "yocto/standard/preempt-rt/base" >>>>>> +#SRCREV_machine_pn-linux-yocto-rt_crownbay-noemgd ?= XXXX >>>>>> +#SRCREV_meta_pn-linux-yocto-rt_crownbay-noemgd ?= XXXX >>>>>> + >>>>>> +#KBRANCH_crownbay = "yocto/standard/preempt-rt/base" >>>>>> +#SRCREV_machine_pn-linux-yocto-rt_crownbay ?= XXXX >>>>>> +#SRCREV_meta_pn-linux-yocto-rt_crownbay ?= XXXX >>>>>> diff --git a/meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend b/meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend >>>>>> new file mode 100644 >>>>>> index 0000000..3b02076 >>>>>> --- /dev/null >>>>>> +++ b/meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend >>>>>> @@ -0,0 +1,17 @@ >>>>>> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" >>>>>> + >>>>>> +COMPATIBLE_MACHINE_crownbay = "crownbay" >>>>>> +KMACHINE_crownbay = "crownbay" >>>>>> +KBRANCH_crownbay = "standard/default/crownbay" >>>>> >>>>> I believe crownbay no longer requires special patches right? Can we just >>>>> use the standard/default/base branch here and squash the crownbay branch? >>>>> >>>> >>>> At the moment it doesn't, and I'll probably submit a patch to do that >>>> for everything that it make sense for again after things are functional >>>> with the simple changes first. >>> >>> There's one catch with this. We currently have the graphics drivers staged as >>> topic branches so they can be in tree, and be kept pristine. The BSPs merge >>> the graphics topic branch they want, and we can leverage common commits >>> across all the users. >>> >>> If you drop the BSP branch, then the graphics changes need to be universally >>> safe for all similar BSPs, since that merge will now be to a shared branch. >>> That's normally fine, but for the case where we have multiple emgd versions, >>> it can break things. >>> >>> We have complete flexibility to how we stage the branches, and how we >>> generate the content that is built, so this can change .. but that's >>> how we currently >>> have it setup. Those graphics merges are board specific changes and require >>> a branch. >>> >> >> That's fine, I'm perfectly happy to have per-BSP machine branches. >> They're cheap, and I don't really see the reason to be so parsimonious >> with them. Also, they're always there, so if we do need to have a place >> to put the odd machine-specific patch now and then we don't have to add >> a new branch when we need to add those patches, or remove them once >> they're gone. I guess the system was kind of designed for that (machine >> branches, even if empty)? > > Exactly. We can collapse them where it makes sense, and keep there where > we need them. A machine branch is just that, a topic branch for development > and implicit documentation of a supported board. If a board may be extended > in the future .. a branch is nice to have. > > I'm in favour of keeping the count in control, but see no need to collapse > them down completely. That and I spent an hour trying to figure out > how to do some fancy merge logic and while it could be done, it just > makes things more complex. I'd prefer branches to overly complex > branch management logic. > Agreed on the concept. What I'm not understanding is how is having to get yocto/emgd-1.10 to merge with standard/base any different than having to get it to merge with: standard/default/crownbay standard/default/common-pc-64/sugarbay standard/default/fri2 etc. emgd isn't premerged into these machine branches if I understand the scc files correctly, so how is this any different? (I'm sure it is, I trust you here, I would just like to understand what I'm missing). -- Darren > Cheers, > > Bruce > >> >>> >>>> >>>>>> +KERNEL_FEATURES_append_crownbay += " cfg/smp.scc" >>>>>> + >>>>>> +COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd" >>>>>> +KMACHINE_crownbay-noemgd = "crownbay" >>>>>> +KBRANCH_crownbay-noemgd = "standard/default/crownbay" >>>>>> +KERNEL_FEATURES_append_crownbay-noemgd += " cfg/smp.scc" >>>>>> + >>>>>> +SRCREV_machine_pn-linux-yocto_crownbay ?= "4471c11c7755727219b673cb887d8a13b8715aba" >>>>>> +SRCREV_meta_pn-linux-yocto_crownbay ?= "64840f55ee144e9814278eaa8e3f33dd60da892c" >>>>>> + >>>>>> +SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "4471c11c7755727219b673cb887d8a13b8715aba" >>>>>> +SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "64840f55ee144e9814278eaa8e3f33dd60da892c" >>>>> >>>>> The meta SRCREV shouldn't be unique from the base linux-yocto_3.2.bb >>>>> recipe, so this can be dropped and save the effort of updating it later. >>>>> >>>> >>>> I don't really want to let the meta SRCREV float - I've run into a >>>> couple nasty problems in the past letting that happen. i.e. nobody does >>>> runtime testing of the BSPs when they change the meta SRCREV in the base >>>> recipe. >>> >>> runtime testing is the hard part. I can build them .. but can't boot them all! >>> >> >> Exactly, which is why I'm happy to push the SRCREVs for a BSP once I've >> tested it... >> >> Tom >> >>> Cheers, >>> >>> Bruce >>> >>>> >>>>> If we use the standard/default/base branch, the machine SRCREV can also >>>>> be dropped. >>>>> >>>> >>>> Agreed, if the machine branch changes to standard/default/base, I'll >>>> change that too. >>>> >>>> Tom >>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> yocto mailing list >>>> yocto@yoctoproject.org >>>> https://lists.yoctoproject.org/listinfo/yocto >>> >>> >>> >> >> >> _______________________________________________ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel