[RFC] Raising the UBI version

[Michal Suchanek]

On 22 June 2016 at 14:43, Boris Brezillon
<boris.brezillon at free-electrons.com> wrote:
> On Tue, 21 Jun 2016 21:19:50 +0200
> Richard Weinberger <richard at nod.at> wrote:
>
>> Dear MTD folks,
>>
>> For the emerging MLC NAND support we need to change the UBI on-flash format.
>> Of course existing UBI images will keep working and remain fully supported.
>> Our approach to deal with MLC (and basically TLC) NAND is LEB consolidation.
>> In this operation mode a single PEB can host multiple LEBs. In the MLC case 2,
>> for TLC 3. For more details please refer to my announcement[0].
>> Hosting multiple LEBs in a single PEB means that beside of a single EC header,
>> a PEB will carry multiple VID headers, one for each LEB it contains.
>> This change needs to be annotated in the EC header.
>>
>> Both EC and VID headers have a version field. Currently it is set to 1. Our
>> original plan was just raising UBI_VERSION to 2, and, of course, accept
>> version 1 image as well. The first hassle was that UBI_VERSION is exported
>> in /sys/class/ubi/version and libubi refuses to work if the version is not 1.
>> Breaking existing userspace tools is not acceptable, so we need another
>> approach.
>>
>> LEB consolidation is not really a completely new UBI implementation, it is
>> an addon feature. So we came up with the idea of having feature flags in
>> the EC header. Maybe we need later more flags, who knows?
>>
>> Boris and I sat down and came up with two possible ways to implement such
>> flags:
>>
>> i) Rename ->version in EC and VID headers to ->features. ->features will
>>    be evaluated at attach time and UBI has to figure whether it supports
>>    all request features. The field is one byte long, therefore we can encode
>>    8 features.
>>    As starter two features would be supported:
>>       UBI_FEAT_BASE   = 1
>>       UBI_FEAT_CONSO  = 2
>>    That means regular UBI images on SLC would only have set UBI_FEAT_BASE and
>>    nothing else. Existing UBI implementations would see ->features with
>>    UBI_FEAT_BASE set as ->version = 1, so we're safe. On MLC NAND we'd set
>>    UBI_FEAT_BASE and UBI_FEAT_CONSO which would be seen as ->version = 3 and
>>    rejected by UBI implementations which do not support LEB consolidation.
>>    To not break userspace tools /sys/class/ubi/version would be hardcoded to 1
>>    and the ->features field exported in /sys/class/ubi/features and
>>    /sys/class/ubi/ubiX/features_used. The features sysfs file denotes what
>>    features this UBI implementation supports and features_used shows what
>>    features the attached UBI image requested. If we change the UBI on-flash
>>    format in a major way, UBI_FEAT_BASE would not be set.
>>
>> ii) Keep ->version in EC and VID headers and use padding bytes from both headers
>>     to add a new ->features field. If ->version is 1, ->features will remain 0
>>     and not evaluated. If ->features should be evaluated, ->version will be 2.
>>     So, on MLC NAND ->version will be 2 and ->features has UBI_FEAT_CONSO set.
>>     This approach is less complicated but we have to claim padding bytes.
>>     Of course we also have to hardcode /sys/class/ubi/version to 1 too and having
>>     a features file in sysfs.
>
> Why do we need to hardcode /sys/class/ubi/version to 1? We just need to
> update the mtd-utils to support version 2. Am I missing something?

Is some code change required in mtd-utils other than the change in
version check?

If not why force everyone to patch their mtd-utils to support doing
the same thing when the file reads back 2 instead of 1?

Thanks

Michal