meta-intel: crownbay 3.2 update
cover meta-intel: crownbay 3.2 update
From: Tom Zanussi <[email protected]>
This updates crownbay and crownbay-noemgd to the 3.2 kernel. It also fixes a problem seen with a missing emgd dependency when testing.
The following changes since commit d9132cc66316be45f44beeea6eba734bb3ab337d:
Tom Zanussi (1):
ia32-base: remove libc-headers PREFERRED_PROVIDER
are available in the git repository at:
git://git.yoctoproject.org/meta-intel.git tzanussi/crownbay-kernel-3.2-switch
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/log/?h=tzanussi/crownbay-kernel-3.2-switch
Tom Zanussi (2):
meta-crownbay: switch to linux-yocto-3.2 kernel
ia32-base: add libva display dependencies to emgd xserver
conf/machine/include/ia32-base.inc | 3 +++ 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 +++++++++++++++++ 5 files changed, 44 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
PATCH 1/2 meta-crownbay: switch to linux-yocto-3.2 kernel
From: Tom Zanussi <[email protected]>
Switch crownbay and crownbay-noemgd to the 3.2 kernel.
--- 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
meta-crownbay/conf/machine/crownbay-noemgd.conf +2 -0
@@ -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
meta-crownbay/conf/machine/crownbay.conf +2 -0
@@ -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
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +20 -0
@@ -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" + +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
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +17 -0
@@ -0,0 +1,17 @@ +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" + +COMPATIBLE_MACHINE_crownbay = "crownbay" +KMACHINE_crownbay = "crownbay" +KBRANCH_crownbay = "standard/default/crownbay" +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"
Signature · 1 line
1.7.0.4
PATCH 2/2 ia32-base: add libva display dependencies to emgd xserver
From: Tom Zanussi <[email protected]>
libgstmixvideoplugin.so is being blacklisted due to a missing libva-tpi library, so add it and make the other two libva display libraries available while we're at it.
--- conf/machine/include/ia32-base.inc | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
conf/machine/include/ia32-base.inc +3 -0
@@ -54,6 +54,9 @@ XSERVER_IA32_I915 = "xf86-video-intel \ XSERVER_IA32_EMGD = "emgd-driver-bin \ libva-x11 \ + libva-tpi \ + libva-glx \ + libva-egl \ " XSERVER_IA32_VESA = "xf86-video-vesa"
Signature · 1 line
1.7.0.4
Re: [PATCH 1/2] meta-crownbay: switch to linux-yocto-3.2 kernel
In reply to [email protected]Hi Tom,
Some thoughts on this with respect to cleaning up and simplifying the recipes per our earlier discussions.
Quoted 46 lines · On 03/12/2012 09:37 PM, [email protected] wrote:
From: Tom Zanussi <[email protected]>
Switch crownbay and crownbay-noemgd to the 3.2 kernel.
Signed-off-by Tom Zanussi <[email protected]>--- 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.bbappendmeta-crownbay/conf/machine/crownbay-noemgd.conf +2
-0@@ -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.incmeta-crownbay/conf/machine/crownbay.conf +2
-0@@ -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.incmeta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +0
-0
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend line 6
Quoted 6 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +6
-0@@ -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.
Quoted 20 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +14
-0+ +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 ?= XXXXmeta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +0
-0
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend line 5
Quoted 5 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +5
-0@@ -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?
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend line 17
Quoted 12 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +12
-0+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.
If we use the standard/default/base branch, the machine SRCREV can also be dropped.
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Re: [PATCH 1/2] meta-crownbay: switch to linux-yocto-3.2 kernel
Quoted 46 lines · Darren Hart
Hi Tom,
Some thoughts on this with respect to cleaning up and simplifying the recipes per our earlier discussions.
Quoted 40 lines · On 03/12/2012 09:37 PM, [email protected] wrote:
From: Tom Zanussi <[email protected]>
Switch crownbay and crownbay-noemgd to the 3.2 kernel.
Signed-off-by Tom Zanussi <[email protected]>--- 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.bbappendmeta-crownbay/conf/machine/crownbay-noemgd.conf +2
-0@@ -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.incmeta-crownbay/conf/machine/crownbay.conf +2
-0@@ -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
Quoted 17 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend line 6
Quoted 12 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +6
-0@@ -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.
Quoted 20 lines
Quoted 20 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +14
-0+ +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 ?= XXXXmeta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +0
-0@@ -0,0 +1,17 @@
Quoted 9 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend line 5
Quoted 5 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +5
-0+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.
Quoted 7 lines
Quoted 7 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +7
-0+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" +
Quoted 9 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend line 17
Quoted 5 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +5
-0+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.
Quoted 3 lines
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
Quoted 1 line
Re: [PATCH 1/2] meta-crownbay: switch to linux-yocto-3.2 kernel
Quoted 100 lines · Tom Zanussi
Quoted 46 lines · Darren Hart
Hi Tom,
Some thoughts on this with respect to cleaning up and simplifying the recipes per our earlier discussions.
Quoted 40 lines · On 03/12/2012 09:37 PM, [email protected] wrote:
From: Tom Zanussi <[email protected]>
Switch crownbay and crownbay-noemgd to the 3.2 kernel.
Signed-off-by Tom Zanussi <[email protected]>---
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
meta-crownbay/conf/machine/crownbay-noemgd.conf +2
-0@@ -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.incmeta-crownbay/conf/machine/crownbay.conf +2
-0@@ -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.incQuoted 17 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend line 6
Quoted 12 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +6
-0@@ -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.
Quoted 20 lines
Quoted 20 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +14
-0+ +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 ?= XXXXmeta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +0
-0@@ -0,0 +1,17 @@Quoted 9 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend line 5
Quoted 5 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +5
-0+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?
Quoted 3 lines
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.
Quoted 18 lines
Quoted 17 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend line 17
Quoted 13 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +12
-0+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.
Quoted 4 lines
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!
Cheers,
Bruce
Quoted 17 lines
Quoted 4 lines
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
Quoted 1 line
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Re: [PATCH 1/2] meta-crownbay: switch to linux-yocto-3.2 kernel
Quoted 115 lines · Bruce Ashfield
Quoted 100 lines · Tom Zanussi
Quoted 46 lines · Darren Hart
Hi Tom,
Some thoughts on this with respect to cleaning up and simplifying the recipes per our earlier discussions.
Quoted 40 lines · On 03/12/2012 09:37 PM, [email protected] wrote:
From: Tom Zanussi <[email protected]>
Switch crownbay and crownbay-noemgd to the 3.2 kernel.
Signed-off-by Tom Zanussi <[email protected]>--- 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.bbappendmeta-crownbay/conf/machine/crownbay-noemgd.conf +2
-0@@ -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.incmeta-crownbay/conf/machine/crownbay.conf +2
-0@@ -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.incQuoted 17 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend line 6
Quoted 12 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +6
-0@@ -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.
Quoted 20 lines
Quoted 20 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +14
-0+ +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 ?= XXXXmeta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +0
-0@@ -0,0 +1,17 @@Quoted 9 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend line 5
Quoted 5 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +5
-0+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?
Quoted 3 lines
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.
Quoted 6 lines
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)?
Quoted 19 lines
Quoted 19 lines
Quoted 18 lines
Quoted 4 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +2
-0+KERNEL_FEATURES_append_crownbay += " cfg/smp.scc" +meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend line 17
Quoted 10 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +10
-0+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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 24 lines
Cheers,
Bruce
Quoted 17 lines
Quoted 4 lines
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
Quoted 1 line
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
Re: [PATCH 1/2] meta-crownbay: switch to linux-yocto-3.2 kernel
Quoted 123 lines · Tom Zanussi
Quoted 115 lines · Bruce Ashfield
Quoted 100 lines · Tom Zanussi
Quoted 46 lines · Darren Hart
Hi Tom,
Some thoughts on this with respect to cleaning up and simplifying the recipes per our earlier discussions.
Quoted 40 lines · On 03/12/2012 09:37 PM, [email protected] wrote:
From: Tom Zanussi<[email protected]>
Switch crownbay and crownbay-noemgd to the 3.2 kernel.
Signed-off-by Tom Zanussi<[email protected]>--- 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
meta-crownbay/conf/machine/crownbay-noemgd.conf +2
-0@@ -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.incmeta-crownbay/conf/machine/crownbay.conf +2
-0@@ -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.incQuoted 17 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend line 6
Quoted 12 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +6
-0@@ -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.
Quoted 20 lines
Quoted 20 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +14
-0+ +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 ?= XXXXmeta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +0
-0@@ -0,0 +1,17 @@Quoted 9 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend line 5
Quoted 5 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +5
-0+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?
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
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.
Cheers,
Bruce
Quoted 63 lines
Quoted 20 lines
Quoted 20 lines
Quoted 19 lines
Quoted 5 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +2
-0+KERNEL_FEATURES_append_crownbay += " cfg/smp.scc" +meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend line 17
Quoted 10 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +10
-0+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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 24 lines
Cheers,
Bruce
Quoted 17 lines
Quoted 4 lines
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
Quoted 1 line
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
Re: [PATCH 1/2] meta-crownbay: switch to linux-yocto-3.2 kernel
Quoted 137 lines · Bruce Ashfield
Quoted 123 lines · Tom Zanussi
Quoted 115 lines · Bruce Ashfield
Quoted 100 lines · Tom Zanussi
Quoted 46 lines · Darren Hart
Hi Tom,
Some thoughts on this with respect to cleaning up and simplifying the recipes per our earlier discussions.
Quoted 40 lines · On 03/12/2012 09:37 PM, [email protected] wrote:
From: Tom Zanussi<[email protected]>
Switch crownbay and crownbay-noemgd to the 3.2 kernel.
Signed-off-by Tom Zanussi<[email protected]>--- 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
meta-crownbay/conf/machine/crownbay-noemgd.conf +2
-0@@ -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.incmeta-crownbay/conf/machine/crownbay.conf +2
-0@@ -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.incQuoted 17 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend line 6
Quoted 12 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +6
-0@@ -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.
Quoted 20 lines
Quoted 20 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +14
-0+ +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 ?= XXXXmeta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +0
-0@@ -0,0 +1,17 @@Quoted 9 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend line 5
Quoted 5 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +5
-0+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?
Quoted 3 lines
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.
Quoted 6 lines
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.Quoted 7 lines
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.
Quoted 6 lines
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
Quoted 68 lines
Cheers,
Bruce
Quoted 63 lines
Quoted 20 lines
Quoted 20 lines
Quoted 19 lines
Quoted 5 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +2
-0+KERNEL_FEATURES_append_crownbay += " cfg/smp.scc" +meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend line 17
Quoted 10 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +10
-0+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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 24 lines
Cheers,
Bruce
Quoted 17 lines
Quoted 4 lines
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
Quoted 1 line
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Re: [PATCH 1/2] meta-crownbay: switch to linux-yocto-3.2 kernel
Quoted 155 lines · Darren Hart
Quoted 137 lines · Bruce Ashfield
Quoted 123 lines · Tom Zanussi
Quoted 115 lines · Bruce Ashfield
Quoted 100 lines · Tom Zanussi
Quoted 46 lines · Darren Hart
Hi Tom,
Some thoughts on this with respect to cleaning up and simplifying the recipes per our earlier discussions.
Quoted 40 lines · On 03/12/2012 09:37 PM, [email protected] wrote:
From: Tom Zanussi<[email protected]>
Switch crownbay and crownbay-noemgd to the 3.2 kernel.
Signed-off-by Tom Zanussi<[email protected]>--- 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
meta-crownbay/conf/machine/crownbay-noemgd.conf +2
-0@@ -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.incmeta-crownbay/conf/machine/crownbay.conf +2
-0@@ -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.incQuoted 17 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend line 6
Quoted 12 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +6
-0@@ -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.
Quoted 20 lines
Quoted 20 lines
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend new file +14
-0+ +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 ?= XXXXmeta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +0
-0@@ -0,0 +1,17 @@Quoted 9 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend line 5
Quoted 5 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +5
-0+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?
Quoted 3 lines
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.
Quoted 6 lines
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.Quoted 7 lines
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.
Quoted 6 lines
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
Quoted 5 lines
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).
When a tree is built from scratch (from the meta data + patch repo), or when BSP validation runs across a tree. All BSPs are constructed in a single tree. If you have merges into common branches, the third, fourth or fifth one is going to eventually explode.
That being said, I *can* inhibit the merges during tree construction and only do it when individual boards are built. But in that scenario, we miss an opportunity for automated/bulk validation that the merges are safe and valid.
So your observation is correct, and it's just a use case of the descriptions
That's why I mentioned that we can collapse them, but there is an increase in complexity. Something to keep in our back pocket, since it's there to use when we need it.
Cheers,
Bruce
Quoted 73 lines
--
DarrenQuoted 68 lines
Cheers,
Bruce
Quoted 63 lines
Quoted 20 lines
Quoted 20 lines
Quoted 19 lines
Quoted 5 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +2
-0+KERNEL_FEATURES_append_crownbay += " cfg/smp.scc" +meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend line 17
Quoted 10 lines
meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend new file +10
-0+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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 24 lines
Cheers,
Bruce
Quoted 17 lines
Quoted 4 lines
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
Quoted 1 line
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
Re: [PATCH 1/2] meta-crownbay: switch to linux-yocto-3.2 kernel
Quoted 8 lines · Bruce Ashfield
Quoted 7 lines · Darren Hart
Quoted 4 lines · Bruce Ashfield
Quoted 3 lines · Tom Zanussi
Quoted 2 lines · Bruce Ashfield
Quoted 1 line · Tom Zanussi
On Tue, 2012-03-13 at 12:30 -0700, Darren Hart wrote:
...
Quoted 55 lines
Quoted 55 lines
Quoted 38 lines
Quoted 25 lines
Quoted 18 lines
Quoted 7 lines
Quoted 3 lines
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.
Quoted 6 lines
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.Quoted 7 lines
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.
Quoted 6 lines
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/fri2etc.
Quoted 8 lines
Quoted 3 lines
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).
When a tree is built from scratch (from the meta data + patch repo), or when BSP validation runs across a tree. All BSPs are constructed in a single tree. If you have merges into common branches, the third, fourth or fifth one is going to eventually explode.
It seems like the obvious answer here is to always create a machine branch during tree construction if one does not already exist. This would address the concerns of automated bulk validation while still keeping the branching in the git tree to a minimum. Very few users will be manipulating the git tree in the WORKDIR, and those that do are expected to be advanced git users that can run:
$ git cherry standard/base
So why do I care about keeping the branch count down?
o It helps make it explicit where we have deviated from mainline.
- Clear visibility into this is one thing that users have complained about.
- It maintains the 1:1 mapping between branches and actual source changes we've discussed.
o It encourages people creating new BSPs to use an existing branch if at all possible.
- We can encourage people to do this, but unless it is clear we are following this advice ourselves, others will not follow.
Taking a hard line on this is also part of boiling down our language and firming up policy and tool definition. Doing so makes things more clear, easier to learn, understand, contribute to, as well as maintain and debug.
--
Darren
Quoted 12 lines
That being said, I *can* inhibit the merges during tree construction and only do it when individual boards are built. But in that scenario, we miss an opportunity for automated/bulk validation that the merges are safe and valid.
So your observation is correct, and it's just a use case of the descriptions
That's why I mentioned that we can collapse them, but there is an increase in complexity. Something to keep in our back pocket, since it's there to use when we need it.
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Re: [PATCH 1/2] meta-crownbay: switch to linux-yocto-3.2 kernel
Quoted 93 lines · Darren Hart
Quoted 8 lines · Bruce Ashfield
Quoted 7 lines · Darren Hart
Quoted 4 lines · Bruce Ashfield
Quoted 3 lines · Tom Zanussi
Quoted 2 lines · Bruce Ashfield
Quoted 1 line · Tom Zanussi
On Tue, 2012-03-13 at 12:30 -0700, Darren Hart wrote:
...
Quoted 55 lines
Quoted 55 lines
Quoted 38 lines
Quoted 25 lines
Quoted 18 lines
Quoted 7 lines
Quoted 3 lines
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.
Quoted 6 lines
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.Quoted 7 lines
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.
Quoted 6 lines
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/fri2etc.
Quoted 8 lines
Quoted 3 lines
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).
When a tree is built from scratch (from the meta data + patch repo), or when BSP validation runs across a tree. All BSPs are constructed in a single tree. If you have merges into common branches, the third, fourth or fifth one is going to eventually explode.
It seems like the obvious answer here is to always create a machine branch during tree construction if one does not already exist. This would address the concerns of automated bulk validation while still keeping the branching in the git tree to a minimum. Very few users will be manipulating the git tree in the WORKDIR, and those that do are expected to be advanced git users that can run:
$ git cherry standard/baseSo why do I care about keeping the branch count down?
o It helps make it explicit where we have deviated from mainline.
- Clear visibility into this is one thing that users have complained about.
- It maintains the 1:1 mapping between branches and actual source changes we've discussed.
Quoted 9 lines
o It encourages people creating new BSPs to use an existing branch if at all possible.
- We can encourage people to do this, but unless it is clear we are following this advice ourselves, others will not follow.Taking a hard line on this is also part of boiling down our language and firming up policy and tool definition. Doing so makes things more clear, easier to learn, understand, contribute to, as well as maintain and debug.
In principle, I agree. The main thing I don't like about it is the potential there is for ping-ponging between having to add a branch because we have a single BSP-specific patch and then having to remove that branch again when it goes upstream or is no longer needed.
Users can use standard git queries to find out whether a machine branch currently has anything that differs from its parent - I'm not sure counting on the existence of a branch as a quick indicator that it deviates from mainline is really all that useful for users, but maybe it is.
In any case, it's a minor point and in the end if it makes things easier for users, that trumps everything else...
Tom
Quoted 18 lines
--
DarrenQuoted 12 lines
That being said, I *can* inhibit the merges during tree construction and only do it when individual boards are built. But in that scenario, we miss an opportunity for automated/bulk validation that the merges are safe and valid.
So your observation is correct, and it's just a use case of the descriptions
That's why I mentioned that we can collapse them, but there is an increase in complexity. Something to keep in our back pocket, since it's there to use when we need it.
Re: [PATCH 1/2] meta-crownbay: switch to linux-yocto-3.2 kernel
In reply to Darren HartQuoted 71 lines · Darren Hart
Quoted 8 lines · Bruce Ashfield
Quoted 7 lines · Darren Hart
Quoted 4 lines · Bruce Ashfield
Quoted 3 lines · Tom Zanussi
Quoted 2 lines · Bruce Ashfield
Quoted 1 line · Tom Zanussi
On Tue, 2012-03-13 at 12:30 -0700, Darren Hart wrote:
...
Quoted 59 lines
Quoted 58 lines
Quoted 38 lines
Quoted 25 lines
Quoted 18 lines
Quoted 7 lines
Quoted 3 lines
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.
Quoted 6 lines
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.Quoted 7 lines
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.
Quoted 6 lines
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/fri2etc.
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).
Quoted 7 lines
Quoted 4 lines
When a tree is built from scratch (from the meta data + patch repo), or when BSP validation runs across a tree. All BSPs are constructed in a single tree. If you have merges into common branches, the third, fourth or fifth one is going to eventually explode.
It seems like the obvious answer here is to always create a machine branch during tree construction if one does not already exist. This
That can be done .. and I've done it in the past, dynamic branches are supported within the tools. But there are always issues:
- anything dynamic is never as smart as someone specifying a feature description and deciding whether or not they want a branch. I've nearly always regretted dynamically creating branches in the past.
- It's not just machine descriptions that trigger merges, any feature can have one if it has a topic branch that is being maintained in that manner. So I tread carefully here to not introduce special cases. We are talking about a known optional, board specific merge. A human can make that call pretty easily and specify that they want a branch.
- Some people just like to build the branch that they want to build. Since, for example, they might be pushing changes onto a non machine specific branch and expecting it to build .. and sometimes that branch isn't even the parent branch (i.e. some temp build). It also means that working in the build tree patches don't have a 1:1 home in a source repository. But there are other things that make this a non-ideal workflow, so I don't really mind making it harder :)
That was the whole intent of KBRANCH. You specify explicitly what you want to build, and the system lets you build that branch. This means that you'll build the same content .. but maybe not that branch.
- Tree generation would have to dynamically create them, and then remove the non-static branches when it completed. Completely doable, but with a complexity cost. Complete tree generation and per-machine building would now differ (although minor).
Quoted 7 lines
would address the concerns of automated bulk validation while still keeping the branching in the git tree to a minimum. Very few users will be manipulating the git tree in the WORKDIR, and those that do are expected to be advanced git users that can run:
$ git cherry standard/base
Quoted 7 lines
So why do I care about keeping the branch count down?
o It helps make it explicit where we have deviated from mainline.
- Clear visibility into this is one thing that users have complained about.
- It maintains the 1:1 mapping between branches and actual source changes we've discussed.
There are far worse examples of non-obvious branches out there, but I don't disagree with the principle.
Quoted 5 lines
o It encourages people creating new BSPs to use an existing branch if at all possible.
- We can encourage people to do this, but unless it is clear we are following this advice ourselves, others will not follow.
I don't really have big problem with people working on machine branches :) It's just a topic branch that holds work, it's like anything you do in a git repo .. do it on your own branch .. and then merge it back.
Anyway, I'm making changes to quite a few things right now in the tools, and we don't want to do this for 1.2, so let me think about this for a day and see if any other use cases break.
Cheers,
Bruce
Quoted 23 lines
Taking a hard line on this is also part of boiling down our language and firming up policy and tool definition. Doing so makes things more clear, easier to learn, understand, contribute to, as well as maintain and debug.
--
DarrenQuoted 12 lines
That being said, I *can* inhibit the merges during tree construction and only do it when individual boards are built. But in that scenario, we miss an opportunity for automated/bulk validation that the merges are safe and valid.
So your observation is correct, and it's just a use case of the descriptions
That's why I mentioned that we can collapse them, but there is an increase in complexity. Something to keep in our back pocket, since it's there to use when we need it.
Re: [PATCH 1/2] meta-crownbay: switch to linux-yocto-3.2 kernel
Quoted 136 lines · Bruce Ashfield
Quoted 71 lines · Darren Hart
Quoted 8 lines · Bruce Ashfield
Quoted 7 lines · Darren Hart
Quoted 4 lines · Bruce Ashfield
Quoted 3 lines · Tom Zanussi
Quoted 2 lines · Bruce Ashfield
Quoted 1 line · Tom Zanussi
On Tue, 2012-03-13 at 12:30 -0700, Darren Hart wrote:
...
Quoted 59 lines
Quoted 58 lines
Quoted 38 lines
Quoted 25 lines
Quoted 18 lines
Quoted 7 lines
Quoted 3 lines
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.
Quoted 6 lines
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.Quoted 7 lines
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.
Quoted 6 lines
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/fri2etc.
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).
Quoted 7 lines
Quoted 4 lines
When a tree is built from scratch (from the meta data + patch repo), or when BSP validation runs across a tree. All BSPs are constructed in a single tree. If you have merges into common branches, the third, fourth or fifth one is going to eventually explode.
It seems like the obvious answer here is to always create a machine branch during tree construction if one does not already exist. This
That can be done .. and I've done it in the past, dynamic branches are supported within the tools. But there are always issues:
- anything dynamic is never as smart as someone specifying a feature description and deciding whether or not they want a branch. I've nearly always regretted dynamically creating branches in the past.
- It's not just machine descriptions that trigger merges, any feature can have one if it has a topic branch that is being maintained in that manner. So I tread carefully here to not introduce special cases. We are talking about a known optional, board specific merge. A human can make that call pretty easily and specify that they want a branch.
- Some people just like to build the branch that they want to build. Since, for example, they might be pushing changes onto a non machine specific branch and expecting it to build .. and sometimes that branch isn't even the parent branch (i.e. some temp build). It also means that working in the build tree patches don't have a 1:1 home in a source repository. But there are other things that make this a non-ideal workflow, so I don't really mind making it harder :)
That was the whole intent of KBRANCH. You specify explicitly what you want to build, and the system lets you build that branch. This means that you'll build the same content .. but maybe not that branch.
- Tree generation would have to dynamically create them, and then remove the non-static branches when it completed. Completely doable, but with a complexity cost. Complete tree generation and per-machine building would now differ (although minor).
Quoted 7 lines
would address the concerns of automated bulk validation while still keeping the branching in the git tree to a minimum. Very few users will be manipulating the git tree in the WORKDIR, and those that do are expected to be advanced git users that can run:
$ git cherry standard/baseQuoted 7 lines
So why do I care about keeping the branch count down?
o It helps make it explicit where we have deviated from mainline.
- Clear visibility into this is one thing that users have complained about.
- It maintains the 1:1 mapping between branches and actual source changes we've discussed.There are far worse examples of non-obvious branches out there, but I don't disagree with the principle.
Quoted 5 lines
o It encourages people creating new BSPs to use an existing branch if at all possible.
- We can encourage people to do this, but unless it is clear we are following this advice ourselves, others will not follow.
Quoted 8 lines
I don't really have big problem with people working on machine branches :) It's just a topic branch that holds work, it's like anything you do in a git repo .. do it on your own branch .. and then merge it back.
Anyway, I'm making changes to quite a few things right now in the tools, and we don't want to do this for 1.2, so let me think about this for a day and see if any other use cases break.
Yes, let's revisit after 1.2 is out. Not need to muddy the waters with it now.
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Re: [PATCH 1/2] meta-crownbay: switch to linux-yocto-3.2 kernel
Quoted 143 lines · Darren Hart
Quoted 140 lines · Bruce Ashfield
Quoted 71 lines · Darren Hart
Quoted 8 lines · Bruce Ashfield
Quoted 7 lines · Darren Hart
Quoted 4 lines · Bruce Ashfield
Quoted 3 lines · Tom Zanussi
Quoted 2 lines · Bruce Ashfield
Quoted 1 line · Tom Zanussi
On Tue, 2012-03-13 at 12:30 -0700, Darren Hart wrote:
...
Quoted 59 lines
Quoted 58 lines
Quoted 38 lines
Quoted 25 lines
Quoted 18 lines
Quoted 7 lines
Quoted 3 lines
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.
Quoted 6 lines
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.Quoted 7 lines
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.
Quoted 6 lines
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/fri2etc.
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).
Quoted 7 lines
Quoted 4 lines
When a tree is built from scratch (from the meta data + patch repo), or when BSP validation runs across a tree. All BSPs are constructed in a single tree. If you have merges into common branches, the third, fourth or fifth one is going to eventually explode.
It seems like the obvious answer here is to always create a machine branch during tree construction if one does not already exist. This
That can be done .. and I've done it in the past, dynamic branches are supported within the tools. But there are always issues:
- anything dynamic is never as smart as someone specifying a feature description and deciding whether or not they want a branch. I've nearly always regretted dynamically creating branches in the past.
- It's not just machine descriptions that trigger merges, any feature can have one if it has a topic branch that is being maintained in that manner. So I tread carefully here to not introduce special cases. We are talking about a known optional, board specific merge. A human can make that call pretty easily and specify that they want a branch.
- Some people just like to build the branch that they want to build. Since, for example, they might be pushing changes onto a non machine specific branch and expecting it to build .. and sometimes that branch isn't even the parent branch (i.e. some temp build). It also means that working in the build tree patches don't have a 1:1 home in a source repository. But there are other things that make this a non-ideal workflow, so I don't really mind making it harder :)
That was the whole intent of KBRANCH. You specify explicitly what you want to build, and the system lets you build that branch. This means that you'll build the same content .. but maybe not that branch.
- Tree generation would have to dynamically create them, and then remove the non-static branches when it completed. Completely doable, but with a complexity cost. Complete tree generation and per-machine building would now differ (although minor).
Quoted 7 lines
would address the concerns of automated bulk validation while still keeping the branching in the git tree to a minimum. Very few users will be manipulating the git tree in the WORKDIR, and those that do are expected to be advanced git users that can run:
$ git cherry standard/baseQuoted 7 lines
So why do I care about keeping the branch count down?
o It helps make it explicit where we have deviated from mainline.
- Clear visibility into this is one thing that users have complained about.
- It maintains the 1:1 mapping between branches and actual source changes we've discussed.There are far worse examples of non-obvious branches out there, but I don't disagree with the principle.
Quoted 5 lines
o It encourages people creating new BSPs to use an existing branch if at all possible.
- We can encourage people to do this, but unless it is clear we are following this advice ourselves, others will not follow.I don't really have big problem with people working on machine branches :) It's just a topic branch that holds work, it's like anything you do in a git repo .. do it on your own branch .. and then merge it back.
Quoted 7 lines
Quoted 4 lines
Anyway, I'm making changes to quite a few things right now in the tools, and we don't want to do this for 1.2, so let me think about this for a day and see if any other use cases break.
Yes, let's revisit after 1.2 is out. Not need to muddy the waters with it now.
+1 .. and I forgot to type in my last email, that all of the points I mention are minor, so really, with the right tweak .. I think this is a fine idea.
Cheers,
Bruce