Hi Tom, Thanks for the rapid reply.
On Mon, Mar 14, 2011 at 12:00 PM, Tom Rini <[email protected]> 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<[email protected]> >> CC: Tom Rini<[email protected]> >> CC: Koen Kooi<[email protected]> >> CC: Denys Dmytriyenko<[email protected]> >> >> --- >> >> 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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
