[OE-core] [PATCH 1/2] classes/image_types: add a variable to list available IMAGE_FSTYPE's
Tom Rini
tom_rini at mentor.com
Wed Jul 13 01:11:13 UTC 2011
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 at 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).
--
Tom Rini
Mentor Graphics Corporation
More information about the Openembedded-core
mailing list