linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
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 21:59:46 +0200	[thread overview]
Message-ID: <576AEE32.5000602@nod.at> (raw)
In-Reply-To: <20160622170633.05321f15@bbrezillon>

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.

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

Thanks,
//richard

  reply	other threads:[~2016-06-22 20:00 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
2016-06-22 14:59                   ` Richard Weinberger
2016-06-22 15:06                     ` Boris Brezillon
2016-06-22 19:59                       ` Richard Weinberger [this message]
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=576AEE32.5000602@nod.at \
    --to=richard@nod.at \
    --cc=alex@nextthing.co \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=linux-mtd@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).