[RFC] Raising the UBI version

Richard Weinberger richard at nod.at
Wed Jun 22 13:24:37 PDT 2016


Am 22.06.2016 um 22:12 schrieb Boris Brezillon:
>> Don't get me wrong, I just want to be sure that all new sysfs files we add
>> have a clear defined use case and won't hurt us later.
> 
> Hm, maybe you're right, exposing this information through sysfs is not
> a requirement, but I think we need to store this information in the EC
> and/or VID headers, so that the UBI implementation can recognize the
> on-flash format.

Sure.

>>
>>>>  
>>>>> - /sys/class/ubi/supported-features: the features supported by the
>>>>>   implementation (each bit is a specific feature or a set of features).
>>>>>   The features may or may not be version dependent.
>>>>> - /sys/class/ubi/ubiX/on-flash-format: the on-flash format used on the
>>>>>   UBIX device
>>>>> - /sys/class/ubi/ubiX/features: the features exposed by this UBIX
>>>>>   device    
>>>>
>>>> I think we should make features depend on version = 2.
>>>> IOW when we change the UBI format in a major way version will be 3 and
>>>> we maybe use something else to expose features.  
>>>
>>> IIUC, we move to version 2 now, because we're using one of the padding
>>> byte (word?) to expose the feature flags, correct?
>>> It makes sense.  
>>
>> I'm not absolutely sure but keeping ->version and adding ->features seems
>> the most feasible solution so far.
> 
> Okay, let's forget what we expose through sysfs for a moment and focus
> on the on-flash format. Do we agree that it's better to keep a version
> field encoding the 'major' version of the on-flash format, and
> introducing a feature field to allow minor backward-compatible
> improvements of a given 'major' version?

Yes. That would be variant ii).

Thanks,
//richard



More information about the linux-mtd mailing list