Re: [PATCH 1/2] classes/image_types: add a variable to list available IMAGE_FSTYPE's

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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<josh@linux.intel.com>
> >>>>> ---
> >>>>>    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