[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