From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Richard Weinberger <richard@nod.at>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Artem Bityutskiy <dedekind1@gmail.com>,
Alexander Kaplan <alex@nextthing.co>,
Brian Norris <computersforpeace@gmail.com>,
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Subject: Re: [RFC] Raising the UBI version
Date: Wed, 22 Jun 2016 16:39:47 +0200 [thread overview]
Message-ID: <20160622163947.36ac7f3e@bbrezillon> (raw)
In-Reply-To: <576A9EF0.9020007@nod.at>
On Wed, 22 Jun 2016 16:21:36 +0200
Richard Weinberger <richard@nod.at> wrote:
> Am 22.06.2016 um 16:13 schrieb Boris Brezillon:
> >> /sys/class/ubi/version is the version of the UBI implementation,
> >> not the version of the attached UBI image.
> >> It will the here as soon you load the UBI module.
> >
> > Do we have /sys/class/ubi/ubiX/version for the UBI image version?
>
> No. That's why I plan to add /sys/class/ubi/ubiX/features_used to
> show which features the attached UBI image requested.
> And having a /sys/class/ubi/ubi/features which denotes what features
> the _implementation_ supports.
Still the version and features are encoding different things IMO.
Incrementing the on-flash version means that the on-flash format has
changed in an incompatible way, while features denotes the fact that
the existing format has been extended with new features but is backward
compatible.
>
> > This is still unclear to me why we need to version the
> > user-space/kernel-space ABI, since it's supposed to be backward
> > compatible, so adding new features requires adding new ioctls and
> > keeping the old ones in a working state.
> >
> > What is /sys/class/ubi/version actually encoding? Isn't it encoding the
> > fact that a specific UBI implementation is supporting all UBI on-flash
> > formats up to format version X (that was my understanding)?
> >
>
> Well, /sys/class/ubi/version exports UBI_VERSION from ubi-media.h.
> It is (ab)used to encode the ABI version *and* the on-flash version.
The on-flash versions supported by the implementation is a useful
information.
> The problem is that mtd-utils libubi will refuse to work with
> /sys/class/ubi/version unequal 1.
>
> Here the gem from libubi:
> if (read_positive_int(lib->ubi_version, &version))
> goto out_error;
> if (version != LIBUBI_UBI_VERSION) {
> errmsg("this library was made for UBI version %d, but UBI "
> "version %d is detected\n", LIBUBI_UBI_VERSION, version);
> goto out_error;
> }
And this is where the problem is: libubi does not make proper use of
this information. We should either have
if (version >= LIBUBI_UBI_VERSION)
or, if we decide that version is a bitfield directly encoding which
versions are supported by the implementation
#define VERSION_SUPPORTED(version, x) ((version) & BIT((x)-1)))
if (VERSION_SUPPORTED(version, 1))
>
> This is why I want to hardcode it to 1.
> Everything else will break existing user space in some way.
> 10 years ago /sys/class/ubi/version seemed like a good idea
> but now it hits us hard.
Yes, I understand that, but this also means /sys/class/ubi/version is
just a dummy file which only purpose is to make libubi happy :).
If this is the case, then I think we should have another file encoding
the supported on-flash formats...
next prev parent reply other threads:[~2016-06-22 14:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-21 19:19 [RFC] Raising the UBI version Richard Weinberger
2016-06-22 12:43 ` Boris Brezillon
2016-06-22 13:09 ` Michal Suchanek
2016-06-22 13:17 ` Boris Brezillon
2016-06-22 13:24 ` Boris Brezillon
2016-06-22 13:54 ` Richard Weinberger
2016-06-22 14:01 ` Boris Brezillon
2016-06-22 14:05 ` Richard Weinberger
2016-06-22 14:13 ` Boris Brezillon
2016-06-22 14:21 ` Richard Weinberger
2016-06-22 14:39 ` Boris Brezillon [this message]
2016-06-22 14:43 ` Richard Weinberger
2016-06-22 14:52 ` Boris Brezillon
2016-06-22 14:59 ` Richard Weinberger
2016-06-22 15:06 ` Boris Brezillon
2016-06-22 19:59 ` Richard Weinberger
2016-06-22 20:12 ` Boris Brezillon
2016-06-22 20:24 ` Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160622163947.36ac7f3e@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=alex@nextthing.co \
--cc=computersforpeace@gmail.com \
--cc=dedekind1@gmail.com \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.