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

login
register
mail settings
Submitter Joshua Lock
Date July 12, 2011, 11:24 p.m.
Message ID <1314a49d823f6e174ca09773cde0fee7ed0e1306.1310511423.git.josh@linux.intel.com>
Download mbox | patch
Permalink /patch/7437/
State New, archived
Headers show

Comments

Joshua Lock - July 12, 2011, 11:24 p.m.
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(-)
Tom Rini - July 12, 2011, 11:38 p.m.
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.
Gary Thomas - July 13, 2011, 12:37 a.m.
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?
Tom Rini - July 13, 2011, 12:44 a.m.
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.
Gary Thomas - July 13, 2011, 12:52 a.m.
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.
Tom Rini - July 13, 2011, 1:11 a.m.
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).
Joshua Lock - July 13, 2011, 2:33 a.m.
On Tue, 2011-07-12 at 16:38 -0700, 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.
> 

Okey dokes, v2 coming up with only ubi listed. If it's as complex as
skimming this thread seems we probably don't want ubifs in a GUI...

Thanks Tom,

Joshua
Richard Purdie - July 13, 2011, 11:24 a.m.
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
Tom Rini - July 13, 2011, 2:10 p.m.
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@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.
Koen Kooi - July 13, 2011, 7:55 p.m.
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@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.

Patch

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"