Skip to contentSkip to conversation

bmaptool support

PATCH In review Ed Bartosh 4 participants 23 messages May 2, 2016 – May 19, 2016

lore
Share & tools
lore

Ed Bartosh

author
#0 lore raw

v3 cover bmaptool support

Hi,

This patchset adds ability to use bmaptool to flash images faster than using traditional methods. It contains bmap-tools recipe and generation of .bmap files for the images generated by bitbake and wic.

Bmaptool is a generic tool for creating the block map (bmap) for a file and and copying files using the block map. The idea is that large file containing unused blocks, like raw system image files, can be copied or flashed a lot faster with bmaptool than with traditional tools like "dd" or "cp".

Here is an example of flashing image using dd and bmaptool showing around 25% performance gain in flashing time:

Quoted 1 line

ls -slh

19M -rw-r--r-- 1 ed ed 26M Apr 26 11:36 core-image-minimal-qemux86-64-20160426083554.rootfs.ext4
4.0K -rw-r--r-- 1 ed ed 2.7K Apr 26 11:36 core-image-minimal-qemux86-64-20160426083554.rootfs.ext4.bmap

Quoted 1 line

time dd if=core-image-minimal-qemux86-64-20160426083554.rootfs.ext4 of=/dev/sdb

52302+0 records in
52302+0 records out
26778624 bytes (27 MB) copied, 2.51183 s, 10.7 MB/s

real    0m2.515s
user    0m0.014s
sys     0m0.329s
Quoted 1 line

time bmaptool copy core-image-minimal-qemux86-64-20160426083554.rootfs.ext4 /dev/sdb

bmaptool: info: discovered bmap file 'core-image-minimal-qemux86-64-20160426083554.rootfs.ext4.bmap'
bmaptool: info: block map format version 2.0
bmaptool: info: 6538 blocks of size 4096 (25.5 MiB), mapped 4799 blocks (18.7 MiB or 73.4%)
bmaptool: info: copying image 'core-image-minimal-qemux86-64-20160426083554.rootfs.ext4' to block device '/dev/sdb' using bmap file 'core-image-minimal-qemux86-64-20160426083554.rootfs.ext4.bmap'
bmaptool: info: 100% copied
bmaptool: info: synchronizing '/dev/sdb'
bmaptool: info: copying time: 1.8s, copying speed 10.3 MiB/sec

real    0m1.909s
user    0m0.226s
sys     0m0.052s

The test was repeated 5 times with the same image and the same usb stick device.

Changes in v2: Combined Alexander's and my bmap-tools recipes.
Got rid of generating standalone script as it breaks build of bmap-tools-native.

Changes in v3: Returned back generation of standalone bmaptool script
Implemented --bmap option for wic
Added test case to test bmap generation by wic --bmap

The following changes since commit f7b520878babbaa7527151f22c031ae160512753:

poky: Switch to post release name/version (2016-04-29 07:58:46 +0100)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib ed/oe-core/bmap-tools-9414
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ed/oe-core/bmap-tools-9414

Alexander D. Kanevskiy (1):
image types: add bmap generation option

Ed Bartosh (5):
bmap-tools: initial commit, version 3.2
selftest: add bmap test
bmap-tools: generate standalone script
wic: implement --bmap option
oe-selftest: wic: add test_bmap test case

 meta/classes/image_types.bbclass                  |  4 ++-
 meta/lib/oeqa/selftest/imagefeatures.py           | 27 +++++++++++++++
 meta/lib/oeqa/selftest/wic.py                     |  8 +++++
 meta/recipes-support/bmap-tools/bmap-tools_3.2.bb | 42 +++++++++++++++++++++++
 scripts/lib/wic/creator.py                        |  1 +
 scripts/lib/wic/engine.py                         | 11 ++++--
 scripts/lib/wic/imager/direct.py                  | 23 ++++++++-----
 scripts/lib/wic/plugins/imager/direct_plugin.py   |  3 +-
 scripts/wic                                       |  3 +-
 9 files changed, 108 insertions(+), 14 deletions(-)
 create mode 100644 meta/recipes-support/bmap-tools/bmap-tools_3.2.bb
Signature · 1 line
2.1.4
author
#1 lore raw

PATCH v3 1/6 bmap-tools: initial commit, version 3.2

Bmap-tools - tools to generate block map (AKA bmap) and flash images using bmap. Bmaptool is a generic tool for creating the block map (bmap) for a file and copying files using the block map.

The idea is that large file containing unused blocks, like raw system image files, can be copied or flashed a lot faster with bmaptool than with traditional tools like "dd" or "cp".

[YOCTO #9414]

---
 meta/recipes-support/bmap-tools/bmap-tools_3.2.bb | 24 +++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 meta/recipes-support/bmap-tools/bmap-tools_3.2.bb
meta/recipes-support/bmap-tools/bmap-tools_3.2.bb new file +24 -0
new file mode 100644
index 0000000..e10f5fd
@@ -0,0 +1,24 @@
+SUMMARY = "Tools to generate block map (AKA bmap) and flash images using bmap"
+DESCRIPTION = "Bmap-tools - tools to generate block map (AKA bmap) and flash images using \
+bmap. Bmaptool is a generic tool for creating the block map (bmap) for a file, \
+and copying files using the block map. The idea is that large file containing \
+unused blocks, like raw system image files, can be copied or flashed a lot \
+faster with bmaptool than with traditional tools like "dd" or "cp"."
+HOMEPAGE = "http://git.infradead.org/users/dedekind/bmap-tools.git"
+SECTION = "console/utils"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
+
+SRC_URI = "ftp://ftp.infradead.org/pub/${BPN}/${BPN}-${PV}.tgz"
+SRC_URI[md5sum] = "92cdad1cb4dfa0cca7176c8e22752616"
+SRC_URI[sha256sum] = "cc6c7f7dc0a37e2a32deb127308e24e6c4b80bfb54f3803c308efab02bf2d434"
+
+RDEPENDS_${PN} = "python-core python-compression"
+
+inherit setuptools
+
+BBCLASSEXTEND = "native"
+
+do_install_append_class-native() {
+    sed -i -e 's|^#!.*/usr/bin/env python|#! /usr/bin/env nativepython|' ${D}${bindir}/bmaptool
+}
Signature · 1 line
2.1.4
author
#2 lore raw

PATCH v3 2/6 image types: add bmap generation option

In reply to Ed Bartosh

From: "Alexander D. Kanevskiy" <[email protected]>

bmap image conversion type allows to create block map files for sparse images. Bmap file can be used together with bmap-tools for efficiently flash images to raw devices (hdd or usb drive)

[YOCTO #9414]

---
 meta/classes/image_types.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
meta/classes/image_types.bbclass +3 -1
index 53af7ca..19f89f3 100644
@@ -262,7 +262,7 @@ IMAGE_TYPES = " \
     wic wic.gz wic.bz2 wic.lzma \
 "
 
-COMPRESSIONTYPES = "gz bz2 lzma xz lz4 sum md5sum sha1sum sha224sum sha256sum sha384sum sha512sum"
+COMPRESSIONTYPES = "gz bz2 lzma xz lz4 sum md5sum sha1sum sha224sum sha256sum sha384sum sha512sum bmap"
 COMPRESS_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
 COMPRESS_CMD_gz = "gzip -f -9 -c ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
 COMPRESS_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
@@ -275,12 +275,14 @@ COMPRESS_CMD_sha224sum = "sha224sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
 COMPRESS_CMD_sha256sum = "sha256sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha256sum"
 COMPRESS_CMD_sha384sum = "sha384sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha384sum"
 COMPRESS_CMD_sha512sum = "sha512sum ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha512sum"
+COMPRESS_CMD_bmap = "bmaptool create ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.bmap"
 COMPRESS_DEPENDS_lzma = "xz-native"
 COMPRESS_DEPENDS_gz = ""
 COMPRESS_DEPENDS_bz2 = "pbzip2-native"
 COMPRESS_DEPENDS_xz = "xz-native"
 COMPRESS_DEPENDS_lz4 = "lz4-native"
 COMPRESS_DEPENDS_sum = "mtd-utils-native"
+COMPRESS_DEPENDS_bmap = "bmap-tools-native"
 
 RUNNABLE_IMAGE_TYPES ?= "ext2 ext3 ext4"
 RUNNABLE_MACHINE_PATTERNS ?= "qemu"
Signature · 1 line
2.1.4
author
#3 lore raw

PATCH v3 3/6 selftest: add bmap test

In reply to Ed Bartosh

Added test_bmap to imagefeatures tests.
It tests if bmap file is generated for the images and if the image is sparse.

[YOCTO #9414]

---
 meta/lib/oeqa/selftest/imagefeatures.py | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)
meta/lib/oeqa/selftest/imagefeatures.py +27 -0
index 8a53899..08e382f 100644
@@ -98,3 +98,30 @@ class ImageFeatures(oeSelfTest):
         # Build a core-image-weston
         bitbake('core-image-weston')
 
+    def test_bmap(self):
+        """
+        Summary:     Check bmap support
+        Expected:    1. core-image-minimal can be build with bmap support
+                     2. core-image-minimal is sparse
+        Product:     oe-core
+        Author:      Ed Bartosh <[email protected]>
+        """
+
+        features = 'IMAGE_FSTYPES += " ext4 ext4.bmap"'
+        self.write_config(features)
+
+        image_name = 'core-image-minimal'
+        bitbake(image_name)
+
+        deploy_dir = get_bb_var('DEPLOY_DIR_IMAGE')
+        link_name = get_bb_var('IMAGE_LINK_NAME', image_name)
+        image_path = os.path.join(deploy_dir, "%s.ext4" % link_name)
+        bmap_path = "%s.bmap" % image_path
+
+        # check if result image and bmap file are in deploy directory
+        self.assertTrue(os.path.exists(image_path))
+        self.assertTrue(os.path.exists(bmap_path))
+
+        # check if result image is sparse
+        image_stat = os.stat(image_path)
+        self.assertTrue(image_stat.st_size > image_stat.st_blocks * 512)
Signature · 1 line
2.1.4
author
#4 lore raw

PATCH v3 4/6 bmap-tools: generate standalone script

In reply to Ed Bartosh

Generated standalone bmaptool script that is more convenient to use than native script. It can be run straight from its location ./tmp/deploy/tools/bmaptool. The script doesn't depend on anything except Python.

---
 meta/recipes-support/bmap-tools/bmap-tools_3.2.bb | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)
meta/recipes-support/bmap-tools/bmap-tools_3.2.bb +19 -1
index e10f5fd..0f95788 100644
@@ -15,10 +15,28 @@ SRC_URI[sha256sum] = "cc6c7f7dc0a37e2a32deb127308e24e6c4b80bfb54f3803c308efab02b
 
 RDEPENDS_${PN} = "python-core python-compression"
 
-inherit setuptools
+inherit setuptools deploy
 
 BBCLASSEXTEND = "native"
 
 do_install_append_class-native() {
     sed -i -e 's|^#!.*/usr/bin/env python|#! /usr/bin/env nativepython|' ${D}${bindir}/bmaptool
 }
+
+do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_TOOLS}"
+do_deploy[stamp-extra-info] = ""
+do_deploy_class-native() {
+    cp bmaptool __main__.py
+    python -m zipfile -c bmaptool.zip bmaptools __main__.py
+    echo '#!/usr/bin/env python' | cat - bmaptool.zip > bmaptool-standalone
+    install -d ${DEPLOYDIR}
+    install -m 0755 bmaptool-standalone ${DEPLOYDIR}/bmaptool-${PV}
+    rm -f ${DEPLOYDIR}/bmaptool
+    ln -sf ./bmaptool-${PV} ${DEPLOYDIR}/bmaptool
+}
+
+do_deploy() {
+    :
+}
+
+addtask deploy before do_package after do_install
Signature · 1 line
2.1.4
author
#18 lore raw

PATCH v3 5/6 wic: implement --bmap option

In reply to Ed Bartosh

This option enables generation of <image>.bmap file for the result image using native bmaptool.

[YOCTO #9413]

---
 scripts/lib/wic/creator.py                      |  1 +
 scripts/lib/wic/engine.py                       | 11 ++++++++---
 scripts/lib/wic/imager/direct.py                | 23 +++++++++++++++--------
 scripts/lib/wic/plugins/imager/direct_plugin.py |  3 ++-
 scripts/wic                                     |  3 ++-
 5 files changed, 28 insertions(+), 13 deletions(-)
scripts/lib/wic/creator.py +1 -0
index 5231297..6f4af8d 100644
@@ -69,6 +69,7 @@ class Creator(object):
         optparser.add_option('', '--tmpfs', action='store_true', dest='enabletmpfs',
                              help='Setup tmpdir as tmpfs to accelerate, experimental'
                                   ' feature, use it if you have more than 4G memory')
+        optparser.add_option('', '--bmap', action='store_true', help='generate .bmap')
         return optparser
 
     def postoptparse(self, options):
scripts/lib/wic/engine.py +8 -3
index 76b93e8..9af6eb4 100644
@@ -145,7 +145,7 @@ def list_source_plugins():
 
 def wic_create(wks_file, rootfs_dir, bootimg_dir, kernel_dir,
                native_sysroot, scripts_path, image_output_dir,
-               compressor, debug):
+               compressor, bmap, debug):
     """Create image
 
     wks_file - user-defined OE kickstart file
@@ -156,6 +156,7 @@ def wic_create(wks_file, rootfs_dir, bootimg_dir, kernel_dir,
     scripts_path - absolute path to /scripts dir
     image_output_dir - dirname to create for image
     compressor - compressor utility to compress the image
+    bmap - enable generation of .bmap
 
     Normally, the values for the build artifacts values are determined
     by 'wic -e' from the output of the 'bitbake -e' command given an
@@ -186,8 +187,12 @@ def wic_create(wks_file, rootfs_dir, bootimg_dir, kernel_dir,
 
     crobj = creator.Creator()
 
-    crobj.main(["direct", native_sysroot, kernel_dir, bootimg_dir, rootfs_dir,
-                wks_file, image_output_dir, oe_builddir, compressor or ""])
+    cmdline = ["direct", native_sysroot, kernel_dir, bootimg_dir, rootfs_dir,
+                wks_file, image_output_dir, oe_builddir, compressor or ""]
+    if bmap:
+        cmdline.append('--bmap')
+
+    crobj.main(cmdline)
 
     print "\nThe image(s) were created using OE kickstart file:\n  %s" % wks_file
 
scripts/lib/wic/imager/direct.py +15 -8
index 1937042..1b6272e 100644
@@ -34,7 +34,7 @@ from wic.utils.partitionedfs import Image
 from wic.utils.errors import CreatorError, ImageError
 from wic.imager.baseimager import BaseImageCreator
 from wic.plugin import pluginmgr
-from wic.utils.oe.misc import exec_cmd
+from wic.utils.oe.misc import exec_cmd, exec_native_cmd
 
 disk_methods = {
     "do_install_disk":None,
@@ -52,7 +52,8 @@ class DirectImageCreator(BaseImageCreator):
     """
 
     def __init__(self, oe_builddir, image_output_dir, rootfs_dir, bootimg_dir,
-                 kernel_dir, native_sysroot, compressor, creatoropts=None):
+                 kernel_dir, native_sysroot, compressor, creatoropts=None,
+                 bmap=False):
         """
         Initialize a DirectImageCreator instance.
 
@@ -74,6 +75,7 @@ class DirectImageCreator(BaseImageCreator):
         self.kernel_dir = kernel_dir
         self.native_sysroot = native_sysroot
         self.compressor = compressor
+        self.bmap = bmap
 
     def __get_part_num(self, num, parts):
         """calculate the real partition number, accounting for partitions not
@@ -314,12 +316,17 @@ class DirectImageCreator(BaseImageCreator):
                                                         self.bootimg_dir,
                                                         self.kernel_dir,
                                                         self.native_sysroot)
-        # Compress the image
-        if self.compressor:
-            for disk_name, disk in self.__image.disks.items():
-                full_path = self._full_path(self.__imgdir, disk_name, "direct")
-                msger.debug("Compressing disk %s with %s" % \
-                            (disk_name, self.compressor))
+
+        for disk_name, disk in self.__image.disks.items():
+            full_path = self._full_path(self.__imgdir, disk_name, "direct")
+            # Generate .bmap
+            if self.bmap:
+                msger.debug("Generating bmap file for %s" % disk_name)
+                exec_native_cmd("bmaptool create %s -o %s.bmap" % (full_path, full_path),
+                                self.native_sysroot)
+            # Compress the image
+            if self.compressor:
+                msger.debug("Compressing disk %s with %s" % (disk_name, self.compressor))
                 exec_cmd("%s %s" % (self.compressor, full_path))
 
     def print_outimage_info(self):
scripts/lib/wic/plugins/imager/direct_plugin.py +2 -1
index 6d3f46c..8fe3930 100644
@@ -86,7 +86,8 @@ class DirectPlugin(ImagerPlugin):
                                             kernel_dir,
                                             native_sysroot,
                                             compressor,
-                                            creatoropts)
+                                            creatoropts,
+                                            opts.bmap)
 
         try:
             creator.create()
scripts/wic +2 -1
index 2286f20..c4767ce 100755
@@ -114,6 +114,7 @@ def wic_create_subcommand(args, usage_str):
     parser.add_option("-c", "--compress-with", choices=("gzip", "bzip2", "xz"),
                       dest='compressor',
                       help="compress image with specified compressor")
+    parser.add_option("-m", "--bmap", action="store_true", help="generate .bmap")
     parser.add_option("-v", "--vars", dest='vars_dir',
                       help="directory with <image>.env files that store "
                            "bitbake variables")
@@ -244,7 +245,7 @@ def wic_create_subcommand(args, usage_str):
     print "Creating image(s)...\n"
     engine.wic_create(wks_file, rootfs_dir, bootimg_dir, kernel_dir,
                       native_sysroot, scripts_path, image_output_dir,
-                      options.compressor, options.debug)
+                      options.compressor, options.bmap, options.debug)
 
 
 def wic_list_subcommand(args, usage_str):
Signature · 1 line
2.1.4
author
#19 lore raw

PATCH v3 6/6 oe-selftest: wic: add test_bmap test case

In reply to Ed Bartosh

Tested generation of .bmap file using wic --bmap command line option.

---
 meta/lib/oeqa/selftest/wic.py | 8 ++++++++
 1 file changed, 8 insertions(+)
meta/lib/oeqa/selftest/wic.py +8 -0
index a569fbf..895c6d6 100644
@@ -276,3 +276,11 @@ class Wic(oeSelfTest):
             status, output = qemu.run_serial(command)
             self.assertEqual(1, status, 'Failed to run command "%s": %s' % (command, output))
             self.assertEqual(output, '/dev/root /\r\n/dev/vda3 /mnt')
+
+    def test_bmap(self):
+        """Test generation of .bmap file"""
+        image = "directdisk"
+        status = runCmd("wic create %s -e core-image-minimal --bmap" % image).status
+        self.assertEqual(0, status)
+        self.assertEqual(1, len(glob(self.resultdir + "%s-*direct" % image)))
+        self.assertEqual(1, len(glob(self.resultdir + "%s-*direct.bmap" % image)))
Signature · 1 line
2.1.4
#5 lore raw

Re: [PATCH v3 4/6] bmap-tools: generate standalone script

In reply to Ed Bartosh
Quoted 7 lines · Ed Bartosh

Generated standalone bmaptool script that is more convenient to use than native script. It can be run straight from its location ./tmp/deploy/tools/bmaptool. The script doesn't depend on anything except Python.

You're right that this is very handy, but we hit a problem when building from shared state. This uses do_deploy to deploy bmaptool into DEPLOY_DIR_IMAGE, but IMAGE_DEPENDS only depends on do_populate_sysroot, not do_deploy, so an image build from sstate won't write this script out.

I don't know the right way to fix this, but it's a problem. I just ran into it :)

Signature · 5 lines
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
#6 lore raw

Re: [PATCH v3 4/6] bmap-tools: generate standalone script

Quoted 13 lines · Christopher Larson
Quoted 7 lines · Ed Bartosh

Generated standalone bmaptool script that is more convenient to use than native script. It can be run straight from its location ./tmp/deploy/tools/bmaptool. The script doesn't depend on anything except Python.

Quoted 8 lines

You're right that this is very handy, but we hit a problem when building from shared state. This uses do_deploy to deploy bmaptool into DEPLOY_DIR_IMAGE, but IMAGE_DEPENDS only depends on do_populate_sysroot, not do_deploy, so an image build from sstate won't write this script out.

I don't know the right way to fix this, but it's a problem. I just ran into it :)

Also, the convention is to add do_deploy before do_build, not before do_package, otherwise do_deploy's checksum is included int he checksums of do_package and subsequent tasks, even though its output isn't used by any subsequent tasks.

Signature · 5 lines
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
#20 lore raw
In reply to Ed Bartosh
Quoted 53 lines · Ed Bartosh

Hi,

This patchset adds ability to use bmaptool to flash images faster than using traditional methods. It contains bmap-tools recipe and generation of .bmap files for the images generated by bitbake and wic.

Bmaptool is a generic tool for creating the block map (bmap) for a file and and copying files using the block map. The idea is that large file containing unused blocks, like raw system image files, can be copied or flashed a lot faster with bmaptool than with traditional tools like "dd" or "cp".

Here is an example of flashing image using dd and bmaptool showing around 25% performance gain in flashing time:

Quoted 1 line

ls -slh

19M -rw-r--r-- 1 ed ed 26M Apr 26 11:36
core-image-minimal-qemux86-64-20160426083554.rootfs.ext4 4.0K -rw-r--r-- 1 ed ed 2.7K Apr 26 11:36 core-image-minimal-qemux86-64-20160426083554.rootfs.ext4.bmap

Quoted 1 line

time dd if=core-image-minimal-qemux86-64-20160426083554.rootfs.ext4

of=/dev/sdb
52302+0 records in
52302+0 records out
26778624 bytes (27 MB) copied, 2.51183 s, 10.7 MB/s

real    0m2.515s
user    0m0.014s
sys     0m0.329s
Quoted 1 line

time bmaptool copy

core-image-minimal-qemux86-64-20160426083554.rootfs.ext4 /dev/sdb
bmaptool: info: discovered bmap file 'core-image-minimal-qemux86-64-20160426083554.rootfs.ext4.bmap'
bmaptool: info: block map format version 2.0
bmaptool: info: 6538 blocks of size 4096 (25.5 MiB), mapped 4799 blocks (18.7 MiB or 73.4%)
bmaptool: info: copying image 'core-image-minimal-qemux86-64-20160426083554.rootfs.ext4' to block device '/dev/sdb' using bmap file 'core-image-minimal-qemux86-64-20160426083554.rootfs.ext4.bmap'
bmaptool: info: 100% copied
bmaptool: info: synchronizing '/dev/sdb'
bmaptool: info: copying time: 1.8s, copying speed 10.3 MiB/sec

real    0m1.909s
user    0m0.226s
sys     0m0.052s

The test was repeated 5 times with the same image and the same usb stick device.

Quoted 7 lines

Changes in v2: Combined Alexander's and my bmap-tools recipes.
Got rid of generating standalone script as it breaks build
of bmap-tools-native.

Changes in v3: Returned back generation of standalone bmaptool script
Implemented --bmap option for wic
Added test case to test bmap generation by wic --bmap

I just wanted to say, this + the sparseness series is just awesome. Such a timesaver in my test cycle, particularly on my old macbook which has a usb 2.0 sd card reader :)

Signature · 5 lines
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
author
#21 lore raw
Quoted 60 lines · Christopher Larson
Quoted 57 lines · Ed Bartosh

Hi,

This patchset adds ability to use bmaptool to flash images faster than using traditional methods. It contains bmap-tools recipe and generation of .bmap files for the images generated by bitbake and wic.

Bmaptool is a generic tool for creating the block map (bmap) for a file and and copying files using the block map. The idea is that large file containing unused blocks, like raw system image files, can be copied or flashed a lot faster with bmaptool than with traditional tools like "dd" or "cp".

Here is an example of flashing image using dd and bmaptool showing around 25% performance gain in flashing time:

Quoted 1 line

ls -slh

19M -rw-r--r-- 1 ed ed 26M Apr 26 11:36
core-image-minimal-qemux86-64-20160426083554.rootfs.ext4 4.0K -rw-r--r-- 1 ed ed 2.7K Apr 26 11:36 core-image-minimal-qemux86-64-20160426083554.rootfs.ext4.bmap

Quoted 1 line

time dd if=core-image-minimal-qemux86-64-20160426083554.rootfs.ext4

of=/dev/sdb
52302+0 records in
52302+0 records out
26778624 bytes (27 MB) copied, 2.51183 s, 10.7 MB/s

real    0m2.515s
user    0m0.014s
sys     0m0.329s
Quoted 1 line

time bmaptool copy

core-image-minimal-qemux86-64-20160426083554.rootfs.ext4 /dev/sdb
bmaptool: info: discovered bmap file 'core-image-minimal-qemux86-64-20160426083554.rootfs.ext4.bmap'
bmaptool: info: block map format version 2.0
bmaptool: info: 6538 blocks of size 4096 (25.5 MiB), mapped 4799 blocks (18.7 MiB or 73.4%)
bmaptool: info: copying image 'core-image-minimal-qemux86-64-20160426083554.rootfs.ext4' to block device '/dev/sdb' using bmap file 'core-image-minimal-qemux86-64-20160426083554.rootfs.ext4.bmap'
bmaptool: info: 100% copied
bmaptool: info: synchronizing '/dev/sdb'
bmaptool: info: copying time: 1.8s, copying speed 10.3 MiB/sec

real    0m1.909s
user    0m0.226s
sys     0m0.052s

The test was repeated 5 times with the same image and the same usb stick device.

Changes in v2: Combined Alexander's and my bmap-tools recipes.
Got rid of generating standalone script as it breaks build
of bmap-tools-native.

Quoted 8 lines
Quoted 3 lines

Changes in v3: Returned back generation of standalone bmaptool script
Implemented --bmap option for wic
Added test case to test bmap generation by wic --bmap

I just wanted to say, this + the sparseness series is just awesome. Such a timesaver in my test cycle, particularly on my old macbook which has a usb 2.0 sd card reader :)

Thank you! I also think bmaptool is awesome utility. It can save lots of flushing time especially for the 'very sparse' images.

I had this work in my TODO for quite long time. Now, thanks to Alexander who did almost all hard work, it's eventually coming to oe/yocto.

--
Regards,
Ed

author
#7 lore raw

Re: [PATCH v3 4/6] bmap-tools: generate standalone script

In reply to Christopher Larson
Quoted 21 lines · Christopher Larson
Quoted 18 lines · Christopher Larson
Quoted 7 lines · Ed Bartosh

Generated standalone bmaptool script that is more convenient to use than native script. It can be run straight from its location ./tmp/deploy/tools/bmaptool. The script doesn't depend on anything except Python.

You're right that this is very handy, but we hit a problem when building from shared state. This uses do_deploy to deploy bmaptool into DEPLOY_DIR_IMAGE, but IMAGE_DEPENDS only depends on do_populate_sysroot, not do_deploy, so an image build from sstate won't write this script out.

Quoted 8 lines
Quoted 3 lines

I don't know the right way to fix this, but it's a problem. I just ran into it :)

Also, the convention is to add do_deploy before do_build, not before do_package, otherwise do_deploy's checksum is included int he checksums of do_package and subsequent tasks, even though its output isn't used by any subsequent tasks.

I also found this a bit unusual to put the tool into deploy/tools. That's why I isolated this change. I think it requires some more testing, but the rest of patchset can be accepted without it.

--
Regards,
Ed

#8 lore raw

Re: [PATCH v3 4/6] bmap-tools: generate standalone script

Quoted 32 lines · Ed Bartosh
Quoted 6 lines · Christopher Larson
Quoted 3 lines · Christopher Larson

On Mon, May 2, 2016 at 12:22 PM, Ed Bartosh <

[email protected]>

Quoted 11 lines
Quoted 11 lines
Quoted 7 lines · wrote:

Generated standalone bmaptool script that is more convenient to use than native script. It can be run straight from its location ./tmp/deploy/tools/bmaptool. The script doesn't depend on anything except Python.

You're right that this is very handy, but we hit a problem when

building

Quoted 2 lines
Quoted 2 lines

from shared state. This uses do_deploy to deploy bmaptool into DEPLOY_DIR_IMAGE, but IMAGE_DEPENDS only depends on

do_populate_sysroot,

Quoted 1 line
Quoted 1 line

not do_deploy, so an image build from sstate won't write this script

out.

Quoted 7 lines
Quoted 4 lines

I don't know the right way to fix this, but it's a problem. I just ran into it :)

Also, the convention is to add do_deploy before do_build, not before do_package, otherwise do_deploy's checksum is included int he checksums

Quoted 7 lines

of

Quoted 2 lines

do_package and subsequent tasks, even though its output isn't used by any subsequent tasks.

I also found this a bit unusual to put the tool into deploy/tools. That's why I isolated this change. I think it requires some more testing, but the rest of patchset can be accepted without it.

Yeah, putting it there does require some discussion in general. Personally, I'm in favor of such a thing, because we don't want to put generated convenience tools in the sysroot, since we tell people explicitly to not use sysroot contents directly.

Regarding getting it built for the image, I'd suggest adding something like IMAGE_TASKDEPENDS to image_type.bbclass, which is basically like IMAGE_DEPENDS, but with the task included. I.e. IMAGE_TASKDEPENDS_bmap = "bmap-tools-native:do_deploy". Then you wouldn't need the 'before do_package', and it'd fix the from-sstate usage.

Signature · 5 lines
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
#22 lore raw
In reply to Ed Bartosh
Quoted 5 lines · Ed Bartosh

This patchset adds ability to use bmaptool to flash images faster than
using traditional methods. It contains bmap-tools recipe and generation
of .bmap files for the images generated by bitbake and wic.

I'm happy to merge this assuming it passes testing. Could you resend the two wic changes against master-next please though (which is after the wic python 3 changes). I resolved some of the earlier conflicts but those were getting too involved.

Cheers,

Richard

#13 lore raw

Re: [PATCH v3 4/6] bmap-tools: generate standalone script

In reply to Ed Bartosh
Quoted 39 lines · Ed Bartosh

Generated standalone bmaptool script that is more convenient to use than native script. It can be run straight from its location ./tmp/deploy/tools/bmaptool. The script doesn't depend on anything except Python.

---
 meta/recipes-support/bmap-tools/bmap-tools_3.2.bb | 20
+++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)
meta/recipes-support/bmap-tools/bmap-tools_3.2.bb +0 -0
index e10f5fd..0f95788 100644
@@ -15,10 +15,28 @@ SRC_URI[sha256sum] =

"cc6c7f7dc0a37e2a32deb127308e24e6c4b80bfb54f3803c308efab02b

RDEPENDS_${PN} = "python-core python-compression"

meta/recipes-support/bmap-tools/bmap-tools_3.2.bb +1 -1
-inherit setuptools
+inherit setuptools deploy
 
 BBCLASSEXTEND = "native"
 
 do_install_append_class-native() {
     sed -i -e 's|^#!.*/usr/bin/env python|#! /usr/bin/env

nativepython|' ${D}${bindir}/bmaptool
}

meta/recipes-support/bmap-tools/bmap-tools_3.2.bb +8 -1
+
+do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_TOOLS}"
+do_deploy[stamp-extra-info] = ""
+do_deploy_class-native() {
+    cp bmaptool __main__.py
+    python -m zipfile -c bmaptool.zip bmaptools __main__.py
+    echo '#!/usr/bin/env python' | cat - bmaptool.zip > bmaptool
-standalone
+    install -d ${DEPLOYDIR}

meta/recipes-support/bmap-tools/bmap-tools_3.2.bb SRC_URI[sha256sum] = "cc6c7f7dc0a37e2a32deb127308e24e6c4b80bfb54f3803c308efab02b · line 42

Quoted 10 lines
meta/recipes-support/bmap-tools/bmap-tools_3.2.bb +10 -0
+    install -m 0755 bmaptool-standalone ${DEPLOYDIR}/bmaptool-${PV}
+    rm -f ${DEPLOYDIR}/bmaptool
+    ln -sf ./bmaptool-${PV} ${DEPLOYDIR}/bmaptool
+}
+
+do_deploy() {
+    :
+}
+
+addtask deploy before do_package after do_install

I'm not sure if we want to do this in the first place. Regardless, the addtask here is incorrect too.

Cheers,

Richard

author
#15 lore raw

PATCH 2/4 wic: implement --bmap option

In reply to Ed Bartosh

This option enables generation of <image>.bmap file for the result image using native bmaptool.

[YOCTO #9413]

---
 scripts/lib/wic/creator.py                      |  1 +
 scripts/lib/wic/engine.py                       | 11 ++++++++---
 scripts/lib/wic/imager/direct.py                | 23 +++++++++++++++--------
 scripts/lib/wic/plugins/imager/direct_plugin.py |  3 ++-
 scripts/wic                                     |  3 ++-
 5 files changed, 28 insertions(+), 13 deletions(-)
scripts/lib/wic/creator.py +1 -0
index d4972e8..8f7d150 100644
@@ -69,6 +69,7 @@ class Creator():
         optparser.add_option('', '--tmpfs', action='store_true', dest='enabletmpfs',
                              help='Setup tmpdir as tmpfs to accelerate, experimental'
                                   ' feature, use it if you have more than 4G memory')
+        optparser.add_option('', '--bmap', action='store_true', help='generate .bmap')
         return optparser
 
     def postoptparse(self, options):
scripts/lib/wic/engine.py +8 -3
index 5d35c46..5b10463 100644
@@ -145,7 +145,7 @@ def list_source_plugins():
 
 def wic_create(wks_file, rootfs_dir, bootimg_dir, kernel_dir,
                native_sysroot, scripts_path, image_output_dir,
-               compressor, debug):
+               compressor, bmap, debug):
     """Create image
 
     wks_file - user-defined OE kickstart file
@@ -156,6 +156,7 @@ def wic_create(wks_file, rootfs_dir, bootimg_dir, kernel_dir,
     scripts_path - absolute path to /scripts dir
     image_output_dir - dirname to create for image
     compressor - compressor utility to compress the image
+    bmap - enable generation of .bmap
 
     Normally, the values for the build artifacts values are determined
     by 'wic -e' from the output of the 'bitbake -e' command given an
@@ -186,8 +187,12 @@ def wic_create(wks_file, rootfs_dir, bootimg_dir, kernel_dir,
 
     crobj = creator.Creator()
 
-    crobj.main(["direct", native_sysroot, kernel_dir, bootimg_dir, rootfs_dir,
-                wks_file, image_output_dir, oe_builddir, compressor or ""])
+    cmdline = ["direct", native_sysroot, kernel_dir, bootimg_dir, rootfs_dir,
+                wks_file, image_output_dir, oe_builddir, compressor or ""]
+    if bmap:
+        cmdline.append('--bmap')
+
+    crobj.main(cmdline)
 
     print("\nThe image(s) were created using OE kickstart file:\n  %s" % wks_file)
 
scripts/lib/wic/imager/direct.py +15 -8
index 5a3b655..ffde232 100644
@@ -33,7 +33,7 @@ from wic.utils.partitionedfs import Image
 from wic.utils.errors import CreatorError, ImageError
 from wic.imager.baseimager import BaseImageCreator
 from wic.plugin import pluginmgr
-from wic.utils.oe.misc import exec_cmd
+from wic.utils.oe.misc import exec_cmd, exec_native_cmd
 
 disk_methods = {
     "do_install_disk":None,
@@ -71,7 +71,8 @@ class DirectImageCreator(BaseImageCreator):
     """
 
     def __init__(self, oe_builddir, image_output_dir, rootfs_dir, bootimg_dir,
-                 kernel_dir, native_sysroot, compressor, creatoropts=None):
+                 kernel_dir, native_sysroot, compressor, creatoropts=None,
+                 bmap=False):
         """
         Initialize a DirectImageCreator instance.
 
@@ -93,6 +94,7 @@ class DirectImageCreator(BaseImageCreator):
         self.kernel_dir = kernel_dir
         self.native_sysroot = native_sysroot
         self.compressor = compressor
+        self.bmap = bmap
 
     def __get_part_num(self, num, parts):
         """calculate the real partition number, accounting for partitions not
@@ -333,12 +335,17 @@ class DirectImageCreator(BaseImageCreator):
                                                         self.bootimg_dir,
                                                         self.kernel_dir,
                                                         self.native_sysroot)
-        # Compress the image
-        if self.compressor:
-            for disk_name, disk in self.__image.disks.items():
-                full_path = self._full_path(self.__imgdir, disk_name, "direct")
-                msger.debug("Compressing disk %s with %s" % \
-                            (disk_name, self.compressor))
+
+        for disk_name, disk in self.__image.disks.items():
+            full_path = self._full_path(self.__imgdir, disk_name, "direct")
+            # Generate .bmap
+            if self.bmap:
+                msger.debug("Generating bmap file for %s" % disk_name)
+                exec_native_cmd("bmaptool create %s -o %s.bmap" % (full_path, full_path),
+                                self.native_sysroot)
+            # Compress the image
+            if self.compressor:
+                msger.debug("Compressing disk %s with %s" % (disk_name, self.compressor))
                 exec_cmd("%s %s" % (self.compressor, full_path))
 
     def print_outimage_info(self):
scripts/lib/wic/plugins/imager/direct_plugin.py +2 -1
index 6d3f46c..8fe3930 100644
@@ -86,7 +86,8 @@ class DirectPlugin(ImagerPlugin):
                                             kernel_dir,
                                             native_sysroot,
                                             compressor,
-                                            creatoropts)
+                                            creatoropts,
+                                            opts.bmap)
 
         try:
             creator.create()
scripts/wic +2 -1
index 11c8316..3d33430 100755
@@ -115,6 +115,7 @@ def wic_create_subcommand(args, usage_str):
     parser.add_option("-c", "--compress-with", choices=("gzip", "bzip2", "xz"),
                       dest='compressor',
                       help="compress image with specified compressor")
+    parser.add_option("-m", "--bmap", action="store_true", help="generate .bmap")
     parser.add_option("-v", "--vars", dest='vars_dir',
                       help="directory with <image>.env files that store "
                            "bitbake variables")
@@ -245,7 +246,7 @@ def wic_create_subcommand(args, usage_str):
     print("Creating image(s)...\n")
     engine.wic_create(wks_file, rootfs_dir, bootimg_dir, kernel_dir,
                       native_sysroot, scripts_path, image_output_dir,
-                      options.compressor, options.debug)
+                      options.compressor, options.bmap, options.debug)
 
 
 def wic_list_subcommand(args, usage_str):
Signature · 1 line
2.1.4
author
#14 lore raw

PATCH 1/4 wic: add bmaptool to the list of utilities

In reply to Richard Purdie

Added bmaptool -> bmap-tools pair to the dictionary executable -> recipe as bmaptool is going to be used by wic to generate .bmap file.

[YOCTO #9413]

---
 scripts/lib/wic/utils/oe/misc.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
scripts/lib/wic/utils/oe/misc.py +2 -1
index 0854dfb..fe188c9 100644
@@ -34,7 +34,8 @@ from wic import msger
 from wic.utils import runner
 
 # executable -> recipe pairs for exec_native_cmd
-NATIVE_RECIPES = {"mcopy": "mtools",
+NATIVE_RECIPES = {"bmaptool": "bmap-tools",
+                  "mcopy": "mtools",
                   "mkdosfs": "dosfstools",
                   "mkfs.btrfs": "btrfs-tools",
                   "mkfs.ext2": "e2fsprogs",
Signature · 1 line
2.1.4
author
#16 lore raw

PATCH 3/4 wic: add help for --bmap commandline option

Included description of -m/--bmap option to the help page produced by 'wic help create'.

[YOCTO #9413]

---
 scripts/lib/wic/help.py | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
scripts/lib/wic/help.py +4 -1
index 7dcc717..6395596 100644
@@ -152,7 +152,7 @@ SYNOPSIS
         [-e | --image-name] [-s, --skip-build-check] [-D, --debug]
         [-r, --rootfs-dir] [-b, --bootimg-dir]
         [-k, --kernel-dir] [-n, --native-sysroot] [-f, --build-rootfs]
-        [-c, --compress-with]
+        [-c, --compress-with] [-m, --bmap]
 
 DESCRIPTION
     This command creates an OpenEmbedded image based on the 'OE
@@ -221,6 +221,9 @@ DESCRIPTION
 
     The -c option is used to specify compressor utility to compress
     an image. gzip, bzip2 and xz compressors are supported.
+
+    The -m option is used to produce .bmap file for the image. This file
+    can be used to flash image using bmaptool utility.
 """
 
 wic_list_usage = """
Signature · 1 line
2.1.4
author
#17 lore raw

PATCH 4/4 oe-selftest: wic: add test_bmap test case

In reply to Ed Bartosh

Tested generation of .bmap file using wic --bmap command line option.

---
 meta/lib/oeqa/selftest/wic.py | 8 ++++++++
 1 file changed, 8 insertions(+)
meta/lib/oeqa/selftest/wic.py +8 -0
index a569fbf..895c6d6 100644
@@ -276,3 +276,11 @@ class Wic(oeSelfTest):
             status, output = qemu.run_serial(command)
             self.assertEqual(1, status, 'Failed to run command "%s": %s' % (command, output))
             self.assertEqual(output, '/dev/root /\r\n/dev/vda3 /mnt')
+
+    def test_bmap(self):
+        """Test generation of .bmap file"""
+        image = "directdisk"
+        status = runCmd("wic create %s -e core-image-minimal --bmap" % image).status
+        self.assertEqual(0, status)
+        self.assertEqual(1, len(glob(self.resultdir + "%s-*direct" % image)))
+        self.assertEqual(1, len(glob(self.resultdir + "%s-*direct.bmap" % image)))
Signature · 1 line
2.1.4
#9 lore raw

Re: [PATCH v3 4/6] bmap-tools: generate standalone script

In reply to Christopher Larson
Quoted 19 lines · Christopher Larson
Quoted 4 lines
Quoted 4 lines

Also, the convention is to add do_deploy before do_build, not before do_package, otherwise do_deploy's checksum is included int he checksums

Quoted 8 lines

of

Quoted 1 line

do_package and subsequent tasks, even though its output isn't used by

any

Quoted 1 line

subsequent tasks.

I also found this a bit unusual to put the tool into deploy/tools. That's why I isolated this change. I think it requires some more testing, but the rest of patchset can be accepted without it.

Yeah, putting it there does require some discussion in general. Personally, I'm in favor of such a thing, because we don't want to put generated convenience tools in the sysroot, since we tell people explicitly to not use sysroot contents directly.

Quoted 6 lines

Regarding getting it built for the image, I'd suggest adding something like IMAGE_TASKDEPENDS to image_type.bbclass, which is basically like IMAGE_DEPENDS, but with the task included. I.e. IMAGE_TASKDEPENDS_bmap = "bmap-tools-native:do_deploy". Then you wouldn't need the 'before do_package', and it'd fix the from-sstate usage.

We had some private conversation with Richard about deploy/tools, I'll try to summarize results of our discussion here:

Thing this, that content under deploy/tools/* supposed to be exported to "release" directory, and should not be used by any other tool during normal build/development process.
Those are for usage on another host, where bitbake and content of sysroots are not usually available.
bmaptool is a good example as stand-alone binary that require only python2 and nothing else to run.
Another example is dfu-util-static, which is also, not dependant even on host's libusb even it runs on other host.

So, in general, it's for static/standalone binaries that are supposed to be published as part of "release" of the build, same like deploy/images/*

For any classes, any internals of build process, they never should depend on content of deploy/* and use *-native tools and binaries out of sysroot. E.g. wic require bmap-tool, it should be dependant on presence of bmap-tools-native installed into sysroot, and should be using both modules and binary out of this sysroot.

This is the way how I'm using it inside Ostro Project:

description in our image type class:
https://github.com/ostroproject/meta-ostro/blob/master/meta-ostro/classes/image-dsk.bbclass#L32
https://github.com/ostroproject/meta-ostro/blob/master/meta-ostro/classes/image-dsk.bbclass#L131

actual usage of bmaptools modules from sysroot:
https://github.com/ostroproject/meta-ostro/blob/master/meta-ostro/lib/image-dsk.py#L16

Signature · 1 line
br, Alexander Kanevskiy
#10 lore raw

Re: [PATCH v3 4/6] bmap-tools: generate standalone script

Quoted 42 lines · Alexander Kanevskiy
Quoted 19 lines · Christopher Larson
Quoted 4 lines
Quoted 4 lines

Also, the convention is to add do_deploy before do_build, not before do_package, otherwise do_deploy's checksum is included int he

Quoted 8 lines

checksums of

Quoted 1 line

do_package and subsequent tasks, even though its output isn't used by

any

Quoted 1 line

subsequent tasks.

I also found this a bit unusual to put the tool into deploy/tools. That's why I isolated this change. I think it requires some more testing, but the rest of patchset can be accepted without it.

Yeah, putting it there does require some discussion in general. Personally, I'm in favor of such a thing, because we don't want to put generated convenience tools in the sysroot, since we tell people explicitly to not use sysroot contents directly.

Quoted 6 lines

Regarding getting it built for the image, I'd suggest adding something like IMAGE_TASKDEPENDS to image_type.bbclass, which is basically like IMAGE_DEPENDS, but with the task included. I.e. IMAGE_TASKDEPENDS_bmap = "bmap-tools-native:do_deploy". Then you wouldn't need the 'before do_package', and it'd fix the from-sstate usage.

We had some private conversation with Richard about deploy/tools, I'll try to summarize results of our discussion here:

Thing this, that content under deploy/tools/* supposed to be exported to "release" directory, and should not be used by any other tool during normal build/development process.
Those are for usage on another host, where bitbake and content of sysroots are not usually available.
bmaptool is a good example as stand-alone binary that require only python2 and nothing else to run.
Another example is dfu-util-static, which is also, not dependant even on host's libusb even it runs on other host.

Quoted 9 lines

So, in general, it's for static/standalone binaries that are supposed to be published as part of "release" of the build, same like deploy/images/*

For any classes, any internals of build process, they never should depend on content of deploy/* and use *-native tools and binaries out of sysroot. E.g. wic require bmap-tool, it should be dependant on presence of bmap-tools-native installed into sysroot, and should be using both modules and binary out of this sysroot.

I don't really understand the point you're trying to make here. As far as I can tell, wic put bmaptool into deploy/tools/ as a convenience for the user, not for wic itself to use, so it already does what you're saying it should do.

Signature · 5 lines
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
#11 lore raw

Re: [PATCH v3 4/6] bmap-tools: generate standalone script

Quoted 41 lines · Christopher Larson
Quoted 29 lines · Alexander Kanevskiy
Quoted 6 lines · Christopher Larson
Quoted 2 lines

Yeah, putting it there does require some discussion in general.

Personally, I'm in favor of such a thing, because we don't want to put generated convenience tools in the sysroot, since we tell people explicitly to not use sysroot contents directly.

Quoted 6 lines

Regarding getting it built for the image, I'd suggest adding something like IMAGE_TASKDEPENDS to image_type.bbclass, which is basically like IMAGE_DEPENDS, but with the task included. I.e. IMAGE_TASKDEPENDS_bmap = "bmap-tools-native:do_deploy". Then you wouldn't need the 'before do_package', and it'd fix the from-sstate usage.

We had some private conversation with Richard about deploy/tools, I'll try to summarize results of our discussion here:

Thing this, that content under deploy/tools/* supposed to be exported to "release" directory, and should not be used by any other tool during normal build/development process.
Those are for usage on another host, where bitbake and content of sysroots are not usually available.
bmaptool is a good example as stand-alone binary that require only python2 and nothing else to run.
Another example is dfu-util-static, which is also, not dependant even on host's libusb even it runs on other host.

Quoted 9 lines

So, in general, it's for static/standalone binaries that are supposed to be published as part of "release" of the build, same like deploy/images/*

For any classes, any internals of build process, they never should depend on content of deploy/* and use *-native tools and binaries out of sysroot. E.g. wic require bmap-tool, it should be dependant on presence of bmap-tools-native installed into sysroot, and should be using both modules and binary out of this sysroot.

Quoted 5 lines

I don't really understand the point you're trying to make here. As far as I can tell, wic put bmaptool into deploy/tools/ as a convenience for the user, not for wic itself to use, so it already does what you're saying it should do.

Yeah, to some extend I'm mixing two topics. Most of above is about putting tools into depoloy/* (as Richard raised concern about that).

Second topic is about subject "which part of image or wic should depend on which task". Both me and Ed are trying to understand exact scenario (or even better test case) would trigger issue which lead to idea above of putting dependencies like IMAGE_TASKDEPENDS_bmap = "bmap-tools-native:do_deploy".

My initial idea, while creating support for bmap-tools in Ostro, was that image type would depend on bmap-tools-native.
This recipe is also responsible to handle deploy/*. Code or dependencies of specific image type don't know anything about deploy part, and IMHO should not know.
In case of support in OE-core, I had impression that Ed implemented it same way. However, I didn't check myself part that he did in wic, so not sure about part of your comment "wic put bmaptool into deploy/tools/".

I also tried in my environment to reproduce scenario as you described in some previous mails in this thread:

Quoted 1 line

You're right that this is very handy, but we hit a problem when building

from shared state. This uses do_deploy to deploy bmaptool into DEPLOY_DIR_IMAGE, but IMAGE_DEPENDS only depends > on do_populate_sysroot, not do_deploy, so an image build from sstate won't write this script out.

but don't see issue with it: executing image build where all objects are available in sstate, but bmap-tools-native not present in sysroot leads to execution of following tasks:

$ cat tmp-glibc/work/x86_64-linux/bmap-tools-native/3.2/temp/log.task_order
do_populate_sysroot_setscene (29437): log.do_populate_sysroot_setscene.29437
do_deploy_setscene (29438): log.do_deploy_setscene.29438
do_populate_lic_setscene (29439): log.do_populate_lic_setscene.29439
$

if it for some reason not like that in code that Ed did for OE-core, we need to look at test scenario, investigate and fix the issue.

Signature · 1 line
br, Alexander Kanevskiy
#12 lore raw

Re: [PATCH v3 4/6] bmap-tools: generate standalone script

Quoted 90 lines · Alexander Kanevskiy
Quoted 43 lines · Christopher Larson
Quoted 32 lines · Alexander Kanevskiy
Quoted 6 lines · Christopher Larson
Quoted 2 lines

Yeah, putting it there does require some discussion in general.

Personally, I'm in favor of such a thing, because we don't want to put generated convenience tools in the sysroot, since we tell people explicitly to not use sysroot contents directly.

Quoted 6 lines

Regarding getting it built for the image, I'd suggest adding something like IMAGE_TASKDEPENDS to image_type.bbclass, which is basically like IMAGE_DEPENDS, but with the task included. I.e. IMAGE_TASKDEPENDS_bmap = "bmap-tools-native:do_deploy". Then you wouldn't need the 'before do_package', and it'd fix the from-sstate usage.

We had some private conversation with Richard about deploy/tools, I'll try to summarize results of our discussion here:

Thing this, that content under deploy/tools/* supposed to be exported to "release" directory, and should not be used by any other tool during normal build/development process.
Those are for usage on another host, where bitbake and content of sysroots are not usually available.
bmaptool is a good example as stand-alone binary that require only python2 and nothing else to run.
Another example is dfu-util-static, which is also, not dependant even on host's libusb even it runs on other host.

So, in general, it's for static/standalone binaries that are supposed to be published as part of "release" of the build, same like deploy/images/*

Quoted 7 lines

For any classes, any internals of build process, they never should depend on content of deploy/* and use *-native tools and binaries out of sysroot.
E.g. wic require bmap-tool, it should be dependant on presence of bmap-tools-native installed into sysroot, and should be using both modules and binary out of this sysroot.

Quoted 5 lines

I don't really understand the point you're trying to make here. As far as I can tell, wic put bmaptool into deploy/tools/ as a convenience for the user, not for wic itself to use, so it already does what you're saying it should do.

Yeah, to some extend I'm mixing two topics. Most of above is about putting tools into depoloy/* (as Richard raised concern about that).

Second topic is about subject "which part of image or wic should depend on which task". Both me and Ed are trying to understand exact scenario (or even better test case) would trigger issue which lead to idea above of putting dependencies like IMAGE_TASKDEPENDS_bmap = "bmap-tools-native:do_deploy".

My initial idea, while creating support for bmap-tools in Ostro, was that image type would depend on bmap-tools-native.
This recipe is also responsible to handle deploy/*. Code or dependencies of specific image type don't know anything about deploy part, and IMHO should not know.
In case of support in OE-core, I had impression that Ed implemented it same way. However, I didn't check myself part that he did in wic, so not sure about part of your comment "wic put bmaptool into deploy/tools/".

I also tried in my environment to reproduce scenario as you described in some previous mails in this thread:

Quoted 1 line

You're right that this is very handy, but we hit a problem when building

from shared state. This uses do_deploy to deploy bmaptool into DEPLOY_DIR_IMAGE, but IMAGE_DEPENDS only depends > on do_populate_sysroot, not do_deploy, so an image build from sstate won't write this script out.

but don't see issue with it: executing image build where all objects are available in sstate, but bmap-tools-native not present in sysroot leads to execution of following tasks:

$ cat tmp-glibc/work/x86_64-linux/bmap-tools-native/3.2/temp/log.task_order
do_populate_sysroot_setscene (29437):
log.do_populate_sysroot_setscene.29437
do_deploy_setscene (29438): log.do_deploy_setscene.29438
do_populate_lic_setscene (29439): log.do_populate_lic_setscene.29439
$
Quoted 3 lines

if it for some reason not like that in code that Ed did for OE-core, we need to look at test scenario, investigate and fix the issue.

For what it's worth, I'm no longer able to reproduce this. I did hit it at one point, but it seems fine now. *shrug*

Signature · 5 lines
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics