All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <tom_rini@mentor.com>
To: Ben Gardiner <bengardiner@nanometrics.ca>
Cc: Koen Kooi <koen@openembedded.org>,
	Tom Rini <trini@embeddedalley.com>,
	Denys, arago-devel@gforge.ti.com,
	openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH] bitbake.conf : make IMAGE_CMD_ubifs also produce .rootfs.ubifs
Date: Mon, 14 Mar 2011 09:00:50 -0700	[thread overview]
Message-ID: <4D7E3BB2.6060104@mentor.com> (raw)
In-Reply-To: <1300111886-4102-1-git-send-email-bengardiner@nanometrics.ca>

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



  reply	other threads:[~2011-03-14 16:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-14 14:11 [PATCH] bitbake.conf : make IMAGE_CMD_ubifs also produce .rootfs.ubifs Ben Gardiner
2011-03-14 16:00 ` Tom Rini [this message]
2011-03-14 16:26   ` Ben Gardiner
2011-03-14 17:02     ` Tom Rini
2011-03-14 17:35       ` Ben Gardiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D7E3BB2.6060104@mentor.com \
    --to=tom_rini@mentor.com \
    --cc=arago-devel@gforge.ti.com \
    --cc=bengardiner@nanometrics.ca \
    --cc=koen@openembedded.org \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=trini@embeddedalley.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.