Re: [RFC] Raising the UBI version

[Boris Brezillon <boris.brezillon@free-electrons.com>]

On Wed, 22 Jun 2016 21:59:46 +0200
Richard Weinberger <richard@nod.at> wrote:

> Am 22.06.2016 um 17:06 schrieb Boris Brezillon:
> > On Wed, 22 Jun 2016 16:59:50 +0200
> > Richard Weinberger <richard@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.

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.

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