[OE-core] [PATCH 1/2] classes/image_types: add a variable to list available IMAGE_FSTYPE's
Koen Kooi
koen at dominion.thruhere.net
Wed Jul 13 19:55:46 UTC 2011
Op 13 jul 2011, om 16:10 heeft Tom Rini het volgende geschreven:
> On 07/13/2011 04:24 AM, Richard Purdie wrote:
>> 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 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).
>>
>> 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...
>
> Well, ubifs is unusable without being in a ubi contanier. But a ubi
> container can have anything in it, we just make a simple container to
> give people a starting point.
Being able to generate a eaw ubifs is usefull when you already have
the container and only want to reflash, but don't want to trash the
ubi erase cycle count.
More information about the Openembedded-core
mailing list