[RFC] Raising the UBI version

[Richard Weinberger]

Am 22.06.2016 um 17:06 schrieb Boris Brezillon:
> On Wed, 22 Jun 2016 16:59:50 +0200
> Richard Weinberger <richard at nod.at> wrote:
> 
>> Am 22.06.2016 um 16:52 schrieb Boris Brezillon:
>>> So how about defining the following:
>>> - /sys/class/ubi/version: user-space ABI version (should always be one)  
>>
>> Yes. To not break libubi.
>>
>>> - /sys/class/ubi/supported-on-flash-formats: either a bitfield or an
>>>   integer representing the higher on-flash format version supported by
>>>   the implementation (which implies that implementations have to
>>>   support all on-flash formats up-to supported-on-flash-formats)  
>>
>> We can do that. But who will evaluate this file?
> 
> ubiformat may need that one to check if the provided ubi image is
> supported by the implementation.

What if someone wants to ubiformat (with MLC support) his mtd0 on an old
kernel and then reboots into the new one with MLC support?
I'm not sure if it is wise do forbid that use case since allowing it does not
hurt.

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.

>>
>>> - /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.

Thanks,
//richard