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:52:12 +0200 [thread overview]
Message-ID: <20160622165212.76c17d0a@bbrezillon> (raw)
In-Reply-To: <576AA425.8070705@nod.at>
On Wed, 22 Jun 2016 16:43:49 +0200
Richard Weinberger <richard@nod.at> wrote:
> Am 22.06.2016 um 16:39 schrieb Boris Brezillon:
> > 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.
>
> Yes. But now we have a mix of both. ;-\
>
> >>
> >>> 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))
>
> Yep. But we cannot change already compiled and shipped code.
>
> >>
> >> 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 :).
>
> That's the plan.
>
> > If this is the case, then I think we should have another file encoding
> > the supported on-flash formats...
>
> This is what /sys/class/ubi/features was supposed to do.
Then you still miss the version concept. Again, versions and features
are orthogonal, and you're not guaranteed that we'll never change the
on-flash format in an incompatible way...
So how about defining the following:
- /sys/class/ubi/version: user-space ABI version (should always be one)
- /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)
- /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
next prev parent reply other threads:[~2016-06-22 14:52 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
2016-06-22 14:43 ` Richard Weinberger
2016-06-22 14:52 ` Boris Brezillon [this message]
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=20160622165212.76c17d0a@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.