All of lore.kernel.org
 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 22:24:37 +0200	[thread overview]
Message-ID: <576AF405.3080803@nod.at> (raw)
In-Reply-To: <20160622221207.2b1297d6@bbrezillon>

Am 22.06.2016 um 22:12 schrieb Boris Brezillon:
>> 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.

Sure.

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

Yes. That would be variant ii).

Thanks,
//richard

      reply	other threads:[~2016-06-22 20:25 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
2016-06-22 20:12                         ` Boris Brezillon
2016-06-22 20:24                           ` Richard Weinberger [this message]

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=576AF405.3080803@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 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.