Patchwork kernel.bbclass: add deploy link to KERNEL_IMAGETYPE

login
register
mail settings
Submitter Christopher Larson
Date May 16, 2012, 1:25 a.m.
Message ID <1337131523-8176-1-git-send-email-kergoth@gmail.com>
Download mbox | patch
Permalink /patch/27793/
State Accepted
Commit c1c8d2f3cffc540380c0a5fcdda48d64cbec333a
Headers show

Comments

Christopher Larson - May 16, 2012, 1:25 a.m.
From: Christopher Larson <chris_larson@mentor.com>

It's common to provide a non-machine-suffixed link in DEPLOY_DIR_IMAGE, so
let's be consistent and do so here as well.

Signed-off-by: Christopher Larson <chris_larson@mentor.com>
---
 meta/classes/kernel.bbclass |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
Darren Hart - May 17, 2012, 2:46 p.m.
On 05/15/2012 06:25 PM, Christopher Larson wrote:
> From: Christopher Larson <chris_larson@mentor.com>
> 
> It's common to provide a non-machine-suffixed link in DEPLOY_DIR_IMAGE, so
> let's be consistent and do so here as well.

This of course means that building two machines in the same build dir
will result in overwriting the latest non-machine-suffixed link
(provided they are the same image type).

I agree that sometimes I wished I just had a bzImage, but the current
behavior seems more robust, consistent, and is less prone to user error.

Is there a reason other than aligning with what other packages do to do
this? Which packages do this?

--
Darren

> 
> Signed-off-by: Christopher Larson <chris_larson@mentor.com>
> ---
>  meta/classes/kernel.bbclass |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index a85f130..90af597 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -538,6 +538,7 @@ kernel_do_deploy() {
>  	cd ${DEPLOYDIR}
>  	rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin
>  	ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGE_SYMLINK_NAME}.bin
> +	ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGETYPE}
>  
>  	cp ${COREBASE}/meta/files/deploydir_readme.txt ${DEPLOYDIR}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt
>  }
Koen Kooi - May 17, 2012, 2:58 p.m.
Op 17 mei 2012, om 16:46 heeft Darren Hart het volgende geschreven:

> On 05/15/2012 06:25 PM, Christopher Larson wrote:
>> From: Christopher Larson <chris_larson@mentor.com>
>> 
>> It's common to provide a non-machine-suffixed link in DEPLOY_DIR_IMAGE, so
>> let's be consistent and do so here as well.
> 
> This of course means that building two machines in the same build dir
> will result in overwriting the latest non-machine-suffixed link
> (provided they are the same image type)

Actually it doesn't. At least not on angstrom, shr and slugos:

koen@dominion:/OE/tentacle/sources/meta-angstrom$ git grep DEPLOY_DIR_IMAGE
conf/distro/include/angstrom.inc:DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}"

The above was mentioned a few weeks ago, but it looks like no one but the distros above and Chris care about proper multimachine builds.
Darren Hart - May 18, 2012, 9:50 p.m.
On 05/17/2012 07:58 AM, Koen Kooi wrote:
> 
> Op 17 mei 2012, om 16:46 heeft Darren Hart het volgende geschreven:
> 
>> On 05/15/2012 06:25 PM, Christopher Larson wrote:
>>> From: Christopher Larson <chris_larson@mentor.com>
>>> 
>>> It's common to provide a non-machine-suffixed link in
>>> DEPLOY_DIR_IMAGE, so let's be consistent and do so here as well.
>> 
>> This of course means that building two machines in the same build
>> dir will result in overwriting the latest non-machine-suffixed
>> link (provided they are the same image type)
> 
> Actually it doesn't. At least not on angstrom, shr and slugos:
> 
> koen@dominion:/OE/tentacle/sources/meta-angstrom$ git grep
> DEPLOY_DIR_IMAGE conf/distro/include/angstrom.inc:DEPLOY_DIR_IMAGE =
> "${DEPLOY_DIR}/images/${MACHINE}"

That seems like a good idea to me. It would make more sense to me for
that to be the default. Having a DISTRO define BUILD policy seems a bit
backwards.

Would anyone object to including ${MACHINE} in the deploy dir by default?

> 
> The above was mentioned a few weeks ago, but it looks like no one but
> the distros above and Chris care about proper multimachine builds. 

Awe, you were doing so well up until there.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Patch

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index a85f130..90af597 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -538,6 +538,7 @@  kernel_do_deploy() {
 	cd ${DEPLOYDIR}
 	rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin
 	ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGE_SYMLINK_NAME}.bin
+	ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGETYPE}
 
 	cp ${COREBASE}/meta/files/deploydir_readme.txt ${DEPLOYDIR}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt
 }