[PATCH] bitbake.conf : make IMAGE_CMD_ubifs also produce .rootfs.ubifs

[PATCH] bitbake.conf : make IMAGE_CMD_ubifs also produce .rootfs.ubifs

[Ben Gardiner]

The ubifs image filenames produced by the ubi and ubifs commands differ.

IMAGE_CMD_ubi produces an interim ubifs image
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ; whereas IMAGE_CMD_ubifs
produces a final ubifs image
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img

This results in the undesirable behaviour then when a user specifies
IMAGE_FSTYPES contains ubifs (as opposed to ubi) they get a broken link
${DEPLOY_DIR_IMAGE}/${ROOTFS_IMAGE}-${MACHINE}.ubifs pointing to the
non-existant ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs

Fix the discrepancy by making the IMAGE_CMD_ubifs also produce the
.rootfs.ubifs target like the IMAGE_CMD_ubi does and preserve the old 
.ubifs.img filename as a link for backwards compatibility.

Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
CC: Tom Rini <trini@embeddedalley.com>
CC: Koen Kooi <koen@openembedded.org>
CC: Denys Dmytriyenko <denis@denix.org>

---

Please also consider this patch for inclusion into the 2011.03-maintenance
branch and into arago-oe-dev

The reason I want to be able to address the ubifs image -- and
not the UBI image -- is because I am trying to produce a UBI image from a
a different ubinize config file which will contain both rootfs and
kernel volumes.

I am trying to accomplish this by creating a recipe which depends on the
rootfs and kernel images we use. This recipe needs to synthesize the image
file path, but without this patch it isn't simple since the link
${DEPLOY_DIR_IMAGE}/${ROOTFS_IMAGE}-${MACHINE}.ubifs is broken.

---

 conf/bitbake.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/bitbake.conf b/conf/bitbake.conf
index 903b9b7..49c4263 100644
--- a/conf/bitbake.conf
+++ b/conf/bitbake.conf
@@ -404,7 +404,7 @@ IMAGE_CMD_cpio.xz = "type cpio >/dev/null; cd ${IMAGE_ROOTFS} && (find . | cpio
 IMAGE_CMD_cpio.gz.u-boot = "type cpio >/dev/null; cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | gzip -c -9 >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz) ${EXTRA_IMAGECMD}; mkimage -A ${UBOOT_ARCH} -O linux -T ramdisk -C gzip -n ${IMAGE_NAME} -d ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz.u-boot"
 IMAGE_CMD_cpio.lzma = "type cpio >/dev/null; cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc | lzma -c ${LZMA_COMPRESSION_LEVEL} >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.lzma) ${EXTRA_IMAGECMD}"
 IMAGE_CMD_ubi = "echo \[ubifs\] > ubinize.cfg ; echo mode=ubi >> ubinize.cfg ; echo image=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs >> 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"
-IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img ${MKUBIFS_ARGS}"
+IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ${MKUBIFS_ARGS}; rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img; ln -sf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img"
 
 EXTRA_IMAGECMD = ""
 EXTRA_IMAGECMD_jffs2 = ""
-- 
1.7.1

Re: [PATCH] bitbake.conf : make IMAGE_CMD_ubifs also produce .rootfs.ubifs

[Tom Rini]

On 03/14/2011 07:11 AM, Ben Gardiner wrote:
> The ubifs image filenames produced by the ubi and ubifs commands differ.
>
> IMAGE_CMD_ubi produces an interim ubifs image
> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ; whereas IMAGE_CMD_ubifs
> produces a final ubifs image
> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img
>
> This results in the undesirable behaviour then when a user specifies
> IMAGE_FSTYPES contains ubifs (as opposed to ubi) they get a broken link
> ${DEPLOY_DIR_IMAGE}/${ROOTFS_IMAGE}-${MACHINE}.ubifs pointing to the
> non-existant ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs
>
> Fix the discrepancy by making the IMAGE_CMD_ubifs also produce the
> .rootfs.ubifs target like the IMAGE_CMD_ubi does and preserve the old
> .ubifs.img filename as a link for backwards compatibility.

So, wait.  What's the problem here?  If you do IMAGE_FSTYPES="ubifs" you 
get the interim image which isn't useful normally but is useful if 
you're doing volume management outside of the provided build targets. 
It's not however a valid rootfs target since it can't be used as is.  I 
think what's missing here is just a comment to the effect that most 
people do not want 'ubifs' and they do want 'ubi' as we provide ubifs 
for advanced usages.

>
> Signed-off-by: Ben Gardiner<bengardiner@nanometrics.ca>
> CC: Tom Rini<trini@embeddedalley.com>
> CC: Koen Kooi<koen@openembedded.org>
> CC: Denys Dmytriyenko<denis@denix.org>
>
> ---
>
> Please also consider this patch for inclusion into the 2011.03-maintenance
> branch and into arago-oe-dev

Just as a general comment, I don't want combined requests for 
2011.03-maintenance but do feel free to make the request as soon as it 
hits a mainline tree (and you've done the relevant testing on 
2011.03-maintenance).

> The reason I want to be able to address the ubifs image -- and
> not the UBI image -- is because I am trying to produce a UBI image from a
> a different ubinize config file which will contain both rootfs and
> kernel volumes.
>
> I am trying to accomplish this by creating a recipe which depends on the
> rootfs and kernel images we use. This recipe needs to synthesize the image
> file path, but without this patch it isn't simple since the link
> ${DEPLOY_DIR_IMAGE}/${ROOTFS_IMAGE}-${MACHINE}.ubifs is broken.

So, this is a valid use case (which I was spelling out above, before I 
got down here). but I think you're using the wrong variables.  There 
should be something that maps over to ${IMAGE_NAME}.ubifs.img


>
> ---
>
>   conf/bitbake.conf |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/conf/bitbake.conf b/conf/bitbake.conf
> index 903b9b7..49c4263 100644
> --- a/conf/bitbake.conf
> +++ b/conf/bitbake.conf
> @@ -404,7 +404,7 @@ IMAGE_CMD_cpio.xz = "type cpio>/dev/null; cd ${IMAGE_ROOTFS}&&  (find . | cpio
>   IMAGE_CMD_cpio.gz.u-boot = "type cpio>/dev/null; cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H newc | gzip -c -9>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz) ${EXTRA_IMAGECMD}; mkimage -A ${UBOOT_ARCH} -O linux -T ramdisk -C gzip -n ${IMAGE_NAME} -d ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.gz.u-boot"
>   IMAGE_CMD_cpio.lzma = "type cpio>/dev/null; cd ${IMAGE_ROOTFS}&&  (find . | cpio -o -H newc | lzma -c ${LZMA_COMPRESSION_LEVEL}>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio.lzma) ${EXTRA_IMAGECMD}"
>   IMAGE_CMD_ubi = "echo \[ubifs\]>  ubinize.cfg ; echo mode=ubi>>  ubinize.cfg ; echo image=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs>>  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"
> -IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img ${MKUBIFS_ARGS}"
> +IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ${MKUBIFS_ARGS}; rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img; ln -sf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img"
>
>   EXTRA_IMAGECMD = ""
>   EXTRA_IMAGECMD_jffs2 = ""


-- 
Tom Rini
Mentor Graphics Corporation

Re: [PATCH] bitbake.conf : make IMAGE_CMD_ubifs also produce .rootfs.ubifs

[Ben Gardiner]

Hi Tom,

Thanks for the rapid reply.

On Mon, Mar 14, 2011 at 12:00 PM, Tom Rini <tom_rini@mentor.com> wrote:
>
> On 03/14/2011 07:11 AM, Ben Gardiner wrote:
>>
>> The ubifs image filenames produced by the ubi and ubifs commands differ.
>>
>> IMAGE_CMD_ubi produces an interim ubifs image
>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ; whereas IMAGE_CMD_ubifs
>> produces a final ubifs image
>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img
>>
>> This results in the undesirable behaviour then when a user specifies
>> IMAGE_FSTYPES contains ubifs (as opposed to ubi) they get a broken link
>> ${DEPLOY_DIR_IMAGE}/${ROOTFS_IMAGE}-${MACHINE}.ubifs pointing to the
>> non-existant ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs
>>
>> Fix the discrepancy by making the IMAGE_CMD_ubifs also produce the
>> .rootfs.ubifs target like the IMAGE_CMD_ubi does and preserve the old
>> .ubifs.img filename as a link for backwards compatibility.
>
> So, wait.  What's the problem here?  If you do IMAGE_FSTYPES="ubifs" you get the interim image which isn't useful normally but is
> useful if you're doing volume management outside of the provided build targets. It's not however a valid rootfs target since it can't be
> used as is.  I think what's missing here is just a comment to the effect that most people do not want 'ubifs' and they do want 'ubi' as
> we provide ubifs for advanced usages.

The other way around: If I do IMAGE_FSTYPES="ubifs" then I don't get
the interim .rootfs.ubifs image I get instead a .ubifs.img; the
.ubifs.img extension is different than the extensions produced by the
other IMAGE_CMD's.

I agree that  they are all valid rootfs images -- what is a difficulty
for me is the resulting filename. The symlink 'sugar' provided by
bitbake in ${DEPLOY_DIR_IMAGE} points to broken images: it always
expects the .rootfs.<type> extension.

All other IMAGE_CMD's produce .rootfs.<type>, excecpt for
IMAGE_CMD_UBIFS, which produces .ubifs.img

>>
>> Signed-off-by: Ben Gardiner<bengardiner@nanometrics.ca>
>> CC: Tom Rini<trini@embeddedalley.com>
>> CC: Koen Kooi<koen@openembedded.org>
>> CC: Denys Dmytriyenko<denis@denix.org>
>>
>> ---
>>
>> Please also consider this patch for inclusion into the 2011.03-maintenance
>> branch and into arago-oe-dev
>
> Just as a general comment, I don't want combined requests for 2011.03-maintenance but do feel free to make the request as soon
> as it hits a mainline tree (and you've done the relevant testing on 2011.03-maintenance).

My apologies -- it won't happen again.

>> The reason I want to be able to address the ubifs image -- and
>> not the UBI image -- is because I am trying to produce a UBI image from a
>> a different ubinize config file which will contain both rootfs and
>> kernel volumes.
>>
>> I am trying to accomplish this by creating a recipe which depends on the
>> rootfs and kernel images we use. This recipe needs to synthesize the image
>> file path, but without this patch it isn't simple since the link
>> ${DEPLOY_DIR_IMAGE}/${ROOTFS_IMAGE}-${MACHINE}.ubifs is broken.
>
> So, this is a valid use case (which I was spelling out above, before I got down here). but I think you're using the wrong variables. > There should be something that maps over to ${IMAGE_NAME}.ubifs.img

You nailed the use case. :)

There are additional complications (to me) introduced by the fact that
the full image filename produced by bitbake has the 'ipk' stuff in it
as well so it isn't as simple as synthesizing with .ubifs.img on the
end.

If you are still opposed to the proposed change; i.e. normalizing
IMAGE_CMD_ubifs so that it produces .rootfs.ubifs instead of
.ubifs.img. Could I request your help to suggest how I would
synthesize the following image name:
arago-base-image-glibc-ipk-2010.03-da850-omapl138-evm.ubifs.img

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca

Re: [PATCH] bitbake.conf : make IMAGE_CMD_ubifs also produce .rootfs.ubifs

[Tom Rini]

On 03/14/2011 09:26 AM, Ben Gardiner wrote:
> Hi Tom,
>
> Thanks for the rapid reply.
>
> On Mon, Mar 14, 2011 at 12:00 PM, Tom Rini<tom_rini@mentor.com>  wrote:
>>
>> On 03/14/2011 07:11 AM, Ben Gardiner wrote:
>>>
>>> The ubifs image filenames produced by the ubi and ubifs commands differ.
>>>
>>> IMAGE_CMD_ubi produces an interim ubifs image
>>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ; whereas IMAGE_CMD_ubifs
>>> produces a final ubifs image
>>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img
>>>
>>> This results in the undesirable behaviour then when a user specifies
>>> IMAGE_FSTYPES contains ubifs (as opposed to ubi) they get a broken link
>>> ${DEPLOY_DIR_IMAGE}/${ROOTFS_IMAGE}-${MACHINE}.ubifs pointing to the
>>> non-existant ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs
>>>
>>> Fix the discrepancy by making the IMAGE_CMD_ubifs also produce the
>>> .rootfs.ubifs target like the IMAGE_CMD_ubi does and preserve the old
>>> .ubifs.img filename as a link for backwards compatibility.
>>
>> So, wait.  What's the problem here?  If you do IMAGE_FSTYPES="ubifs" you get the interim image which isn't useful normally but is
>> useful if you're doing volume management outside of the provided build targets. It's not however a valid rootfs target since it can't be
>> used as is.  I think what's missing here is just a comment to the effect that most people do not want 'ubifs' and they do want 'ubi' as
>> we provide ubifs for advanced usages.
>
> The other way around: If I do IMAGE_FSTYPES="ubifs" then I don't get
> the interim .rootfs.ubifs image I get instead a .ubifs.img; the
> .ubifs.img extension is different than the extensions produced by the
> other IMAGE_CMD's.

Right.  The others are a valid rootfs but the ubi isn't because it needs 
that container.

>
> I agree that  they are all valid rootfs images -- what is a difficulty
> for me is the resulting filename. The symlink 'sugar' provided by
> bitbake in ${DEPLOY_DIR_IMAGE} points to broken images: it always
> expects the .rootfs.<type>  extension.
>
> All other IMAGE_CMD's produce .rootfs.<type>, excecpt for
> IMAGE_CMD_UBIFS, which produces .ubifs.img

Would it be OK if we just didn't make the broken link, assuming we make 
the full use case work?

>>> Signed-off-by: Ben Gardiner<bengardiner@nanometrics.ca>
>>> CC: Tom Rini<trini@embeddedalley.com>
>>> CC: Koen Kooi<koen@openembedded.org>
>>> CC: Denys Dmytriyenko<denis@denix.org>
>>>
>>> ---
>>>
>>> Please also consider this patch for inclusion into the 2011.03-maintenance
>>> branch and into arago-oe-dev
>>
>> Just as a general comment, I don't want combined requests for 2011.03-maintenance but do feel free to make the request as soon
>> as it hits a mainline tree (and you've done the relevant testing on 2011.03-maintenance).
>
> My apologies -- it won't happen again.
>
>>> The reason I want to be able to address the ubifs image -- and
>>> not the UBI image -- is because I am trying to produce a UBI image from a
>>> a different ubinize config file which will contain both rootfs and
>>> kernel volumes.
>>>
>>> I am trying to accomplish this by creating a recipe which depends on the
>>> rootfs and kernel images we use. This recipe needs to synthesize the image
>>> file path, but without this patch it isn't simple since the link
>>> ${DEPLOY_DIR_IMAGE}/${ROOTFS_IMAGE}-${MACHINE}.ubifs is broken.
>>
>> So, this is a valid use case (which I was spelling out above, before I got down here). but I think you're using the wrong variables.>  There should be something that maps over to ${IMAGE_NAME}.ubifs.img
>
> You nailed the use case. :)
>
> There are additional complications (to me) introduced by the fact that
> the full image filename produced by bitbake has the 'ipk' stuff in it
> as well so it isn't as simple as synthesizing with .ubifs.img on the
> end.
>
> If you are still opposed to the proposed change; i.e. normalizing
> IMAGE_CMD_ubifs so that it produces .rootfs.ubifs instead of
> .ubifs.img. Could I request your help to suggest how I would
> synthesize the following image name:
> arago-base-image-glibc-ipk-2010.03-da850-omapl138-evm.ubifs.img

I've got an idea or two, but can you give me the full bitbake -e (off 
list of course) on the recipe that puts it all together?  We need for 
this use case to work and I just want to try and make it users that 
'ubifs' is special (and avoid the "I put IMAGES_FSTYPES+=ubifs into my 
local.conf, wrote it to flash and it doesn't work!" emails, but maybe 
that concern is just in my head at this point as UBI isn't as new as it 
used to be).

-- 
Tom Rini
Mentor Graphics Corporation

Re: [PATCH] bitbake.conf : make IMAGE_CMD_ubifs also produce .rootfs.ubifs

[Ben Gardiner]

On Mon, Mar 14, 2011 at 1:02 PM, Tom Rini <tom_rini@mentor.com> wrote:
> On 03/14/2011 09:26 AM, Ben Gardiner wrote:
>>
>> Hi Tom,
>>
>> Thanks for the rapid reply.
>>
>> On Mon, Mar 14, 2011 at 12:00 PM, Tom Rini<tom_rini@mentor.com>  wrote:
>>>
>>> On 03/14/2011 07:11 AM, Ben Gardiner wrote:
>>>>
>>>> The ubifs image filenames produced by the ubi and ubifs commands differ.
>>>>
>>>> IMAGE_CMD_ubi produces an interim ubifs image
>>>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ; whereas IMAGE_CMD_ubifs
>>>> produces a final ubifs image
>>>> ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img
>>>>
>>>> This results in the undesirable behaviour then when a user specifies
>>>> IMAGE_FSTYPES contains ubifs (as opposed to ubi) they get a broken link
>>>> ${DEPLOY_DIR_IMAGE}/${ROOTFS_IMAGE}-${MACHINE}.ubifs pointing to the
>>>> non-existant ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs
>>>>
>>>> Fix the discrepancy by making the IMAGE_CMD_ubifs also produce the
>>>> .rootfs.ubifs target like the IMAGE_CMD_ubi does and preserve the old
>>>> .ubifs.img filename as a link for backwards compatibility.
>>>
>>> So, wait.  What's the problem here?  If you do IMAGE_FSTYPES="ubifs" you
>>> get the interim image which isn't useful normally but is
>>> useful if you're doing volume management outside of the provided build
>>> targets. It's not however a valid rootfs target since it can't be
>>> used as is.  I think what's missing here is just a comment to the effect
>>> that most people do not want 'ubifs' and they do want 'ubi' as
>>> we provide ubifs for advanced usages.
>>
>> The other way around: If I do IMAGE_FSTYPES="ubifs" then I don't get
>> the interim .rootfs.ubifs image I get instead a .ubifs.img; the
>> .ubifs.img extension is different than the extensions produced by the
>> other IMAGE_CMD's.
>
> Right.  The others are a valid rootfs but the ubi isn't because it needs
> that container.

Ok. I think I see the difference you are trying to point out here --
since the UBIFS 'image' requires a UBI volumeas container it is not a
.rootfs.<type> image like the others. I do not object to this
classification of images; but then I request that the IMAGE_CMD_ubi be
modified to not produce a .rootfs.ubifs interim image for consistency.

>> I agree that  they are all valid rootfs images -- what is a difficulty
>> for me is the resulting filename. The symlink 'sugar' provided by
>> bitbake in ${DEPLOY_DIR_IMAGE} points to broken images: it always
>> expects the .rootfs.<type>  extension.
>>
>> All other IMAGE_CMD's produce .rootfs.<type>, excecpt for
>> IMAGE_CMD_UBIFS, which produces .ubifs.img
>
> Would it be OK if we just didn't make the broken link, assuming we make the
> full use case work?

Yes, that would be great -- some notes below.

>>>> Signed-off-by: Ben Gardiner<bengardiner@nanometrics.ca>
>>>> CC: Tom Rini<trini@embeddedalley.com>
>>>> CC: Koen Kooi<koen@openembedded.org>
>>>> CC: Denys Dmytriyenko<denis@denix.org>
>>>>
>>>> ---
>>>>
>>>> Please also consider this patch for inclusion into the
>>>> 2011.03-maintenance
>>>> branch and into arago-oe-dev
>>>
>>> Just as a general comment, I don't want combined requests for
>>> 2011.03-maintenance but do feel free to make the request as soon
>>> as it hits a mainline tree (and you've done the relevant testing on
>>> 2011.03-maintenance).
>>
>> My apologies -- it won't happen again.
>>
>>>> The reason I want to be able to address the ubifs image -- and
>>>> not the UBI image -- is because I am trying to produce a UBI image from
>>>> a
>>>> a different ubinize config file which will contain both rootfs and
>>>> kernel volumes.
>>>>
>>>> I am trying to accomplish this by creating a recipe which depends on the
>>>> rootfs and kernel images we use. This recipe needs to synthesize the
>>>> image
>>>> file path, but without this patch it isn't simple since the link
>>>> ${DEPLOY_DIR_IMAGE}/${ROOTFS_IMAGE}-${MACHINE}.ubifs is broken.
>>>
>>> So, this is a valid use case (which I was spelling out above, before I
>>> got down here). but I think you're using the wrong variables.>  There should
>>> be something that maps over to ${IMAGE_NAME}.ubifs.img
>>
>> You nailed the use case. :)
>>
>> There are additional complications (to me) introduced by the fact that
>> the full image filename produced by bitbake has the 'ipk' stuff in it
>> as well so it isn't as simple as synthesizing with .ubifs.img on the
>> end.
>>
>> If you are still opposed to the proposed change; i.e. normalizing
>> IMAGE_CMD_ubifs so that it produces .rootfs.ubifs instead of
>> .ubifs.img. Could I request your help to suggest how I would
>> synthesize the following image name:
>> arago-base-image-glibc-ipk-2010.03-da850-omapl138-evm.ubifs.img
>
> I've got an idea or two, but can you give me the full bitbake -e (off list
> of course) on the recipe that puts it all together?

Looking forward to hearing your ideas. I'll send you an off-list -e
and recipe shortly.

> We need for this use
> case to work and I just want to try and make it users that 'ubifs' is
> special (and avoid the "I put IMAGES_FSTYPES+=ubifs into my local.conf,
> wrote it to flash and it doesn't work!" emails, but maybe that concern is
> just in my head at this point as UBI isn't as new as it used to be).

I understand your apprehension at the prospect of troves of uninformed
users trying to flash ubifs images 'directly' and subsequently
complaining about it on the lists. Being of the other variety of user,
I would definitely appreciate oe maintaining the current behaviour of
producing .rootfs.ubifs images -- note that a ubifs image is still
useful for 'flashing' with 'ubiupdatevol'.

However, my primary use-case of the .ubifs.rootfs link is for
integration into multi-volume UBI image of my design and since you
have so graciously offered to help make that use-case work I have no
further objections to the removal of the .ubifs.rootfs link. All my
other uses are manual and so hunting through DEPLOY_DIR_IMAGE is
acceptable.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca