Re: [RFC] Raising the UBI version

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

On Wed, 22 Jun 2016 15:54:34 +0200
Richard Weinberger <richard@nod.at> wrote:

> Am 22.06.2016 um 14:43 schrieb Boris Brezillon:
> > 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?  
> 
> We don't want to break existing userspace.
> Why should ubimkvol or ubiattach fail on a system with SLC NAND and
> CONFIG_MTD_UBI_CONSOLIDATE=y?

But version won't be set to 2 in this case. If it's an SLC NAND we
don't need to use UBI version 2, do we.

> 
> Especially since existing tools *will* work with CONFIG_MTD_UBI_CONSOLIDATE=y.
> Rasing /sys/class/ubi/version and breaking existing tools is only acceptable
> when we change all UBI ioctl() and sysfs files in a way such that version 1
> userspace cannot work. Which is not the case here.
> 
> This is a nice example why version numbers is bad and feature flags should be used.
> Currently UBI mixes the implementation version and the on-flash version.
> We're changing only the on-flash version. The user visible ABI stays and will only
> get extended.

Correct. So /sys/class/ubi/version is representing the user-space ABI
version, right? Maybe we should expose the on-flash version in a
different file then.