"Finish" the IMAGE_GEN_DEBUGFS implementation

V3: (hopefully final)
Fixed the comparison by adding the prefix into the image_cmd data structure. That ensures we're only comparing the prefix and not the whole pathname.

Also changed the bb.note slightly to indicate which path we tool through the processing in case of future problems.

V2:
By adjusting the _write_script function (and associated _get_imagecmds) the script may optionally pass in a prefix for the generated script. This solves one of the problems in the prior version. (No more script name collisions.)

The second issue is that the datastore is used to find various parameters (which are different in the DEBUGFS datastore) when doing the final symlink generation.

So we do have to switch (based on the script prefix) which datastore we should be using. (Note, I'm not completely sure that the switch is 'safe', so this is an area that should be verified.)

V1:

It was noticed today that the IMAGE_GEN_DEBUGFS implementation was not complete. The version that was merged back in May only contained the filesystem generation pieces, but not the pieces for creating the image from that filesystem.

The code has been tested and is working. The only thing that I don't particularly like is that the processing code and loop is a duplicate of the code that runs just before. Unfortunately the only way around this is to change the way that way the parallel bits are processed to support multiple datastores.. (or create "another" function..)

Any feedback appreciated, but without this the feature is broken!

Mark Hatle (1):
lib/oe/image.py: Add image generation for companion debug filesystem

 meta/conf/documentation.conf         |  2 ++
 meta/conf/local.conf.sample.extended |  9 +++++++
 meta/lib/oe/image.py                 | 46 +++++++++++++++++++++++++++++-------
 3 files changed, 48 insertions(+), 9 deletions(-)

1.9.3

The companion debug filesystem, enabled with IMAGE_GEN_DEBUGFS, was creating the companion filesystem but was missing the code to actually package it into a usable filesystem.

The code (and associated documentation) will allow the debugfs to generate a companion tarball or other image.

---
 meta/conf/documentation.conf         |  2 ++
 meta/conf/local.conf.sample.extended |  9 +++++++
 meta/lib/oe/image.py                 | 46 +++++++++++++++++++++++++++++-------
 3 files changed, 48 insertions(+), 9 deletions(-)

index 075ab6a..845559a 100644
@@ -212,6 +212,8 @@ IMAGE_BOOT_FILES[doc] = "Whitespace separated list of files from ${DEPLOY_DIR_IM
 IMAGE_CLASSES[doc] = "A list of classes that all images should inherit."
 IMAGE_FEATURES[doc] = "The primary list of features to include in an image. Configure this variable in an image recipe."
 IMAGE_FSTYPES[doc] = "Formats of root filesystem images that you want to have created."
+IMAGE_FSTYPES_DEBUGFS[doc] = "Formats of the debug root filesystem images that you want to have created."
+IMAGE_GEN_DEBUGFS[doc] = "When set to '1', generate a companion debug object/source filesystem image."
 IMAGE_INSTALL[doc] = "Specifies the packages to install into an image. Image recipes set IMAGE_INSTALL to specify the packages to install into an image through image.bbclass."
 IMAGE_LINGUAS[doc] = "Specifies the list of locales to install into the image during the root filesystem construction process."
 IMAGE_NAME[doc] = "The name of the output image files minus the extension."

index ccdd326..bc765a1 100644
@@ -165,6 +165,15 @@
 # currently an example class is image_types_uboot
 # IMAGE_CLASSES = " image_types_uboot"
 
+# The following options will build a companion 'debug filesystem' in addition
+# to the normal deployable filesystem.  This companion system allows a
+# debugger to know the symbols and related sources.  It can be used to
+# debug a remote 'production' system without having to add the debug symbols
+# and sources to remote system.  If IMAGE_FSTYPES_DEBUGFS is not defined, it
+# defaults to IMAGE_FSTYPES.
+#IMAGE_GEN_DEBUGFS = "1"
+#IMAGE_FSTYPES_DEBUGFS = "tar.gz"
+
 # Incremental rpm image generation, the rootfs would be totally removed
 # and re-created in the second generation by default, but with
 # INC_RPM_IMAGE_GEN = "1", the rpm based rootfs would be kept, and will

1.9.3