Skip to contentSkip to conversation

Split IMAGE* variables into a separate class

PATCH Applied Richard Purdie 5 participants 12 messages Mar 24, 2011 – Mar 31, 2011

lore
Share & tools
lore
#0 lore raw

cover Split IMAGE* variables into a separate class

From: Richard Purdie <[email protected]>

These patches split the IMAGE* variables out into a separate class to improve readabilty. The patch descriptions themselves have the details.

Pull URL: git://git.openembedded.org/openembedded-core-contrib
Branch: rpurdie/imagetypes
Browse: http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rpurdie/imagetypes

Thanks,
Richard Purdie <[email protected]>
---

Richard Purdie (2):
bitbake.conf/image.bbclass: Move image type information into
image_types.bbclass
image_types.bbclass: Drop IMAGE_EXTRA_OPTION in favour of the more
standard EXTRA_IMAGECMD

 meta/classes/image.bbclass       |   22 +---------
 meta/classes/image_types.bbclass |   86 ++++++++++++++++++++++++++++++++++++++
 meta/conf/bitbake.conf           |   44 -------------------
 3 files changed, 87 insertions(+), 65 deletions(-)
 create mode 100644 meta/classes/image_types.bbclass
Signature · 1 line
1.7.4.1
#1 lore raw

PATCH 1/2 bitbake.conf/image.bbclass: Move image type information into image_types.bbclass

From: Richard Purdie <[email protected]>

Image generation code in .conf files is hard to read as it needs to be single line. By moving this to a separate class, multiline functions can be used instead improving readability. It also declutters bitbake.conf.

There is no real functional change with this patch but it highlights the need for improvements in places such as the IMAGE_EXTRA_OPTION ext* specific variable which makes no sense.

---
 meta/classes/image.bbclass       |   22 +----------
 meta/classes/image_types.bbclass |   81 ++++++++++++++++++++++++++++++++++++++
 meta/conf/bitbake.conf           |   41 -------------------
 3 files changed, 82 insertions(+), 62 deletions(-)
 create mode 100644 meta/classes/image_types.bbclass
meta/classes/image.bbclass +1 -21
index eb0d970..aa842c7 100644
@@ -64,27 +64,7 @@ def get_devtable_list(d):
         str += " %s" % bb.which(bb.data.getVar('BBPATH', d, 1), devtable)
     return str
 
-def get_imagecmds(d):
-    cmds = "\n"
-    old_overrides = bb.data.getVar('OVERRIDES', d, 0)
-    for type in bb.data.getVar('IMAGE_FSTYPES', d, True).split():
-        localdata = bb.data.createCopy(d)
-        localdata.setVar('OVERRIDES', '%s:%s' % (type, old_overrides))
-        bb.data.update_data(localdata)
-        localdata.setVar('type', type)
-        cmd = localdata.getVar("IMAGE_CMD_" + type, True)
-        localdata.setVar('cmd', cmd)
-        cmds += localdata.getVar("runimagecmd", True)
-    return cmds
-
-runimagecmd () {
-	# Image generation code for image type ${type}
-	ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{size = $1 * ${IMAGE_OVERHEAD_FACTOR}; print (size > ${IMAGE_ROOTFS_SIZE} ? size : ${IMAGE_ROOTFS_SIZE}) }'`
-	${cmd}
-	cd ${DEPLOY_DIR_IMAGE}/
-	rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.${type}
-	ln -s ${IMAGE_NAME}.rootfs.${type} ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.${type}
-}
+inherit image_types
 
 IMAGE_POSTPROCESS_COMMAND ?= ""
 MACHINE_POSTPROCESS_COMMAND ?= ""
meta/classes/image_types.bbclass new file +81 -0

81 lines not on this page · raw message

meta/conf/bitbake.conf +0 -41

47 lines not on this page · raw message

Signature · 1 line
1.7.4.1
#2 lore raw

cover port oe-dev ,ubifs.img link support

I made some changes in oe-dev to normalize the link names used for the ubifs images created when the type is ubifs vs. when the type is UBI. The changes we two-fold: make symlinks to either .rootfs.<type> or <type>.img and use the <type>.img extension for the ubifs images when they are intermediate for UBI image generation as well as the final target.

The changes were accepted by Tom Rini for oe-dev and Denys Dmytriyenko for arago.

I've only just begun following the oe-core list and I noticed your (Richard's) changes to introduce image_type.bbclass to oe-core. When I looked closer at the changes I could see that there had been no sync-up from oe-dev to oe-core since the changes I mentioned above.

This changeset should align oe-core with those recent changes in oe-dev; the changes I made were dependent on Bernhard's change to replace the symlink target with 'ln -f' instead of 'rm'ing it first; so I ported his commit also.

I'm sorry to say that there has been no testing of these changes with oe-core. I would be interested in trying a test build... but I must admit I don't know what MACHINE+DISTRO+image to try as a simple test build.

Ben Gardiner (2):
image_types.bbclass: add link to .rootfs.<type> or .<type>.img image_types.bbclass: use .ubifs.img extension in IMAGE_CMD_ubi

Bernhard Reutner-Fischer (1):
image_types.bbclass: rm symlink destination via ln

 meta/classes/image_types.bbclass | 11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)
#3 lore raw

PATCH 1/3 image_types.bbclass: rm symlink destination via ln

From: Bernhard Reutner-Fischer <[email protected]>

( This is a port of commit ffdf56431d26ce54377d672764a8bba61dcaf853 from git://git.openembedded.org/openembedded )

Rather than rm'ing the destination-file manually, do ln -f

---
 meta/classes/image_types.bbclass |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)
meta/classes/image_types.bbclass +1 -2
index f11a7ed..696e978 100644
@@ -16,8 +16,7 @@ runimagecmd () {
 	ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{size = $1 * ${IMAGE_OVERHEAD_FACTOR}; print (size > ${IMAGE_ROOTFS_SIZE} ? size : ${IMAGE_ROOTFS_SIZE}) }'`
 	${cmd}
 	cd ${DEPLOY_DIR_IMAGE}/
-	rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.${type}
-	ln -s ${IMAGE_NAME}.rootfs.${type} ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.${type}
+	ln -fs ${IMAGE_NAME}.rootfs.${type} ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.${type}
 }
 
 IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 ${EXTRA_IMAGECMD}"
Signature · 1 line
1.7.0.4
#4 lore raw

PATCH 2/3 image_types.bbclass: add link to .rootfs.<type> or .<type>.img

In reply to Ben Gardiner

( This is a port of commit cfde49e8d0f1cf09d589910f1a342849db148519 from git://git.openembedded.org/openembedded )

The current image link-creation code will unconditionaly create a link from .<type> pointing to the .rootfs.<type> output.

This is not compatible with the UBIFS images produced which have .<type>.img extension since they are not considered to be valid rootfs images when they are not included in a UBI container.

Check for existence of the link target .rootfs.<type> before creating the link and fallback to a check for the .<type>.img target after that.

---
 meta/classes/image_types.bbclass |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)
meta/classes/image_types.bbclass +5 -1
index 696e978..6a66d21 100644
@@ -16,7 +16,11 @@ runimagecmd () {
 	ROOTFS_SIZE=`du -ks ${IMAGE_ROOTFS}|awk '{size = $1 * ${IMAGE_OVERHEAD_FACTOR}; print (size > ${IMAGE_ROOTFS_SIZE} ? size : ${IMAGE_ROOTFS_SIZE}) }'`
 	${cmd}
 	cd ${DEPLOY_DIR_IMAGE}/
-	ln -fs ${IMAGE_NAME}.rootfs.${type} ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.${type}
+	if [ -f ${IMAGE_NAME}.rootfs.${type} ]; then
+		ln -fs ${IMAGE_NAME}.rootfs.${type} ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.${type}
+	elif [ -f ${IMAGE_NAME}.${type}.img ]; then
+		ln -fs ${IMAGE_NAME}.${type}.img ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.${type}
+	fi
 }
 
 IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 ${EXTRA_IMAGECMD}"
Signature · 1 line
1.7.0.4
#5 lore raw

PATCH 3/3 image_types.bbclass: use .ubifs.img extension in IMAGE_CMD_ubi

In reply to Ben Gardiner

( This is a port of 7308e68fc26cdbffa08d311a2319c8d1c3b2805f from git://git.openembedded.org/openembedded )

The current IMAGE_CMD_ubi creates an interim image with a .rootfs.ubifs extension.

The ubifs image created is not considered a valid rootfs without a UBI container.

Change the filename of the iterim ubifs image used by IMAGE_CMD_ubi to .ubifs.img to match the IMAGE_CMD_ubifs command.

---
 meta/classes/image_types.bbclass |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
meta/classes/image_types.bbclass +2 -2
index 6a66d21..1bfe6fd 100644
@@ -56,12 +56,12 @@ IMAGE_CMD_cpio.gz = "cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | gzip -c -
 IMAGE_CMD_ubi () {
 	echo \[ubifs\] > ubinize.cfg 
 	echo mode=ubi >> ubinize.cfg
-	echo image=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs >> ubinize.cfg 
+	echo image=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img >> ubinize.cfg
 	echo vol_id=0 >> ubinize.cfg 
 	echo vol_type=dynamic >> ubinize.cfg 
 	echo vol_name=${UBI_VOLNAME} >> ubinize.cfg 
 	echo vol_flags=autoresize >> ubinize.cfg
-	mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ${MKUBIFS_ARGS} && ubinize -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubi ${UBINIZE_ARGS} ubinize.cfg
+	mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img ${MKUBIFS_ARGS} && ubinize -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubi ${UBINIZE_ARGS} ubinize.cfg
 }
 IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img ${MKUBIFS_ARGS}"
 
Signature · 1 line
1.7.0.4
Acked-by on the v1 series
#6 lore raw

Re: [PATCH 0/3] port oe-dev ,ubifs.img link support

In reply to Ben Gardiner
Quoted 28 lines · Ben Gardiner

I made some changes in oe-dev to normalize the link names used for the ubifs images created when the type is ubifs vs. when the type is UBI. The changes we two-fold: make symlinks to either .rootfs.<type> or <type>.img and use the <type>.img extension for the ubifs images when they are intermediate for UBI image generation as well as the final target.

The changes were accepted by Tom Rini for oe-dev and Denys Dmytriyenko for arago.

I've only just begun following the oe-core list and I noticed your (Richard's) changes to introduce image_type.bbclass to oe-core. When I looked closer at the changes I could see that there had been no sync-up from oe-dev to oe-core since the changes I mentioned above.

This changeset should align oe-core with those recent changes in oe-dev; the changes I made were dependent on Bernhard's change to replace the symlink target with 'ln -f' instead of 'rm'ing it first; so I ported his commit also.

I'm sorry to say that there has been no testing of these changes with oe-core. I would be interested in trying a test build... but I must admit I don't know what MACHINE+DISTRO+image to try as a simple test build.

Ben Gardiner (2):
image_types.bbclass: add link to .rootfs.<type> or .<type>.img image_types.bbclass: use .ubifs.img extension in IMAGE_CMD_ubi

Quoted 5 lines

Bernhard Reutner-Fischer (1):
image_types.bbclass: rm symlink destination via ln

 meta/classes/image_types.bbclass | 11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

Thanks for doing this. The whole series looks good to me,

Signature · 2 lines
Tom Rini
Mentor Graphics Corporation
Acked-by on the v1 series
#7 lore raw

Re: [PATCH 0/3] port oe-dev ,ubifs.img link support

In reply to Ben Gardiner
Quoted 6 lines · Ben Gardiner

I made some changes in oe-dev to normalize the link names used for the ubifs images created when the type is ubifs vs. when the type is UBI. The changes we two-fold: make symlinks to either .rootfs.<type> or <type>.img and use the <type>.img extension for the ubifs images when they are intermediate for UBI image generation as well as the final target.

Ben,

That seems like a good patchset for oe-core at this point. Especially in the light of Richard's proposal for image_types.bbclass...

Quoted 32 lines

The changes were accepted by Tom Rini for oe-dev and Denys Dmytriyenko for arago.

I've only just begun following the oe-core list and I noticed your (Richard's) changes to introduce image_type.bbclass to oe-core. When I looked closer at the changes I could see that there had been no sync-up from oe-dev to oe-core since the changes I mentioned above.

This changeset should align oe-core with those recent changes in oe-dev; the changes I made were dependent on Bernhard's change to replace the symlink target with 'ln -f' instead of 'rm'ing it first; so I ported his commit also.

I'm sorry to say that there has been no testing of these changes with oe-core. I would be interested in trying a test build... but I must admit I don't know what MACHINE+DISTRO+image to try as a simple test build.

Ben Gardiner (2):
image_types.bbclass: add link to .rootfs.<type> or .<type>.img image_types.bbclass: use .ubifs.img extension in IMAGE_CMD_ubi

Bernhard Reutner-Fischer (1):
image_types.bbclass: rm symlink destination via ln

 meta/classes/image_types.bbclass | 11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

#8 lore raw

PATCH 2/2 image_types.bbclass: Drop IMAGE_EXTRA_OPTION in favour of the more standard EXTRA_IMAGECMD

In reply to Richard Purdie

From: Richard Purdie <[email protected]>

---
 meta/classes/image_types.bbclass |   13 +++++++++----
 meta/conf/bitbake.conf           |    3 ---
 2 files changed, 9 insertions(+), 7 deletions(-)
meta/classes/image_types.bbclass +9 -4
index 5c9bcd1..f11a7ed 100644
@@ -23,21 +23,21 @@ runimagecmd () {
 IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --faketime --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 ${EXTRA_IMAGECMD}"
 IMAGE_CMD_yaffs2 = "mkyaffs2image ${EXTRA_IMAGECMD} ${IMAGE_ROOTFS} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.yaffs2"
 IMAGE_CMD_cramfs = "mkcramfs ${IMAGE_ROOTFS} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cramfs ${EXTRA_IMAGECMD}"
-IMAGE_CMD_ext2 = "genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS} ${IMAGE_EXTRA_OPTION} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext2 ${EXTRA_IMAGECMD}"
+IMAGE_CMD_ext2 = "genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext2"
 IMAGE_CMD_ext2.gz () {
 	rm -rf ${DEPLOY_DIR_IMAGE}/tmp.gz && mkdir ${DEPLOY_DIR_IMAGE}/tmp.gz
-	genext2fs -b ${IMAGE_ROOTFS_SIZE} -d ${IMAGE_ROOTFS} ${IMAGE_EXTRA_OPTION} ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext2 ${EXTRA_IMAGECMD}
+	genext2fs -b ${IMAGE_ROOTFS_SIZE} -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD} ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext2
 	gzip -f -9 ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext2
 	mv ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext2.gz ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext2.gz
 	rmdir ${DEPLOY_DIR_IMAGE}/tmp.gz
 }
 IMAGE_CMD_ext3 () {
-	genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS} ${IMAGE_EXTRA_OPTION} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3 ${EXTRA_IMAGECMD}
+	genext2fs -b $ROOTFS_SIZE -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD} ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3
 	tune2fs -j ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3
 }
 IMAGE_CMD_ext3.gz () {
 	rm -rf ${DEPLOY_DIR_IMAGE}/tmp.gz && mkdir ${DEPLOY_DIR_IMAGE}/tmp.gz
-	genext2fs -b ${IMAGE_ROOTFS_SIZE} -d ${IMAGE_ROOTFS} ${IMAGE_EXTRA_OPTION} ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext3 ${EXTRA_IMAGECMD}
+	genext2fs -b ${IMAGE_ROOTFS_SIZE} -d ${IMAGE_ROOTFS} ${EXTRA_IMAGECMD} ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext3
 	tune2fs -j ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext3
 	gzip -f -9 ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext3
 	mv ${DEPLOY_DIR_IMAGE}/tmp.gz/${IMAGE_NAME}.rootfs.ext3.gz ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3.gz
@@ -65,6 +65,11 @@ IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_
 EXTRA_IMAGECMD = ""
 EXTRA_IMAGECMD_jffs2 = "--pad --little-endian --eraseblock=0x40000"
 EXTRA_IMAGECMD_yaffs2 = "1"
+# Change these if you want default genext2fs behavior (i.e. create minimal inode number)
+EXTRA_IMAGECMD_ext2 ?= "-i 8192"
+EXTRA_IMAGECMD_ext2.gz ?= "-i 8192"
+EXTRA_IMAGECMD_ext3 ?= "-i 8192"
+EXTRA_IMAGECMD_ext3.gz ?= "-i 8192"
 
 IMAGE_DEPENDS = ""
 IMAGE_DEPENDS_jffs2 = "mtd-utils-native"
meta/conf/bitbake.conf +0 -3
index 8e89945..6b6b2ee 100644
@@ -352,9 +352,6 @@ IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}"
 # fixed extra space
 IMAGE_OVERHEAD_FACTOR ?= 1.3
 
-# Comment this option if you want default genext2fs behavior (i.e. create minimal inode number)
-IMAGE_EXTRA_OPTION ?= "-i 8192"
-
 EXTRA_IMAGEDEPENDS = ""
 
 ##################################################################
Signature · 1 line
1.7.4.1
#10 lore raw
Quoted 9 lines · Koen Kooi

Op 24 mrt 2011, om 15:49 heeft Richard Purdie het volgende geschreven:

Quoted 4 lines

From: Richard Purdie<[email protected]>

These patches split the IMAGE* variables out into a separate class to improve readabilty.

I like it!

Agreed. This will help us clean up the N instances of make an ext2 image, modify.

Signature · 2 lines
Tom Rini
Mentor Graphics Corporation
author Applied
#11 lore raw
In reply to Richard Purdie
Quoted 14 lines · Richard Purdie

From: Richard Purdie <[email protected]>

These patches split the IMAGE* variables out into a separate class to improve readabilty. The patch descriptions themselves have the details.

Pull URL: git://git.openembedded.org/openembedded-core-contrib
Branch: rpurdie/imagetypes
Browse: http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rpurdie/imagetypes

Thanks,
Richard Purdie <[email protected]>
---

Quoted 5 lines

Richard Purdie (2):
bitbake.conf/image.bbclass: Move image type information into
image_types.bbclass
image_types.bbclass: Drop IMAGE_EXTRA_OPTION in favour of the more
standard EXTRA_IMAGECMD

I've merged these to master.

Cheers,

Richard