On Tue, 2011-07-12 at 18:11 -0700, Tom Rini wrote: > On 07/12/2011 05:52 PM, Gary Thomas wrote: > > On 07/12/2011 06:44 PM, Tom Rini wrote: > >> On 07/12/2011 05:37 PM, Gary Thomas wrote: > >>> On 07/12/2011 05:38 PM, Tom Rini wrote: > >>>> On 07/12/2011 04:24 PM, Joshua Lock wrote: > >>>>> This is for use in the Hob GUI to enable the user to change the type > >>>>> of the > >>>>> generated image. > >>>>> > >>>>> Signed-off-by: Joshua Lock<[email protected]> > >>>>> --- > >>>>> meta/classes/image_types.bbclass | 2 ++ > >>>>> 1 files changed, 2 insertions(+), 0 deletions(-) > >>>>> > >>>>> diff --git a/meta/classes/image_types.bbclass > >>>>> b/meta/classes/image_types.bbclass > >>>>> index 89a745c..29d7a57 100644 > >>>>> --- a/meta/classes/image_types.bbclass > >>>>> +++ b/meta/classes/image_types.bbclass > >>>>> @@ -102,3 +102,5 @@ IMAGE_DEPENDS_cpio.xz = "xz-native" > >>>>> IMAGE_DEPENDS_ubi = "mtd-utils-native" > >>>>> IMAGE_DEPENDS_ubifs = "mtd-utils-native" > >>>>> > >>>>> +# This variable is available to request which values are suitable > >>>>> for IMAGE_FSTYPES > >>>>> +IMAGE_TYPES = "jffs2 cramfs ext2 ext2.gz ext3 ext3.gz squashfs > >>>>> squashfs-lzma ubi ubifs" > >>>> > >>>> Concept is fine, but please don't list ubi and ubifs just list ubi. > >>> > >>> Perhaps the [brokwn] rule to explicitly build ubifs should also be > >>> purged? > >> > >> Nope, that's how the ubi is created. Essentially at the time anyhow, OE > >> didn't make it too easy to add in an image that needs to be in a > >> container to be used. So we have the ubifs rule (yes, that needs a > >> cherry-pick from oe.dev) for 'advanced' users and the ubi rule to create > >> a simple ubi image. > > > > I might be missing something, but I don't see why this rule is necessary > > in image_types.bbclass: > > IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o > > ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ubifs.img ${MKUBIFS_ARGS}" > > > > Having it there leads to the confusion (I was) that ubifs was useful. > > > > At least for me, I can build ubi images with that rule removed. > > OK, refreshed my memory again. We have ubifs (and it might indeed need > some quick kicking/fixing) target (a) since that's what was there to > start with, but not quite enough (b) for advanced users. There is a > point to making a ubifs image which is when you're making a complex ubi > volume (either outside of OE or in your collection/layer that provides a > more complex ubinize conf). > > The problem in oe-core today is that we were using non-standard > extensions on the ubifs part to try and distinguish between usable > standalone files (ubi) and parts (ubifs).
Surely if you're doing this extra processing, you could just define the IMAGE_CMD_ubifs variable too? I'm a little worried about having something there that is effectively unusable on its own... Cheers, Richard _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
