public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Frank Haverkamp <f.haverkamp@web.de>
To: dedekind@infradead.org
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBI fixes
Date: Fri, 06 Oct 2006 09:56:19 +0200	[thread overview]
Message-ID: <1160121379.5460.29.camel@localhost.localdomain> (raw)
In-Reply-To: <1159956864.13696.25.camel@sauron>

Hi Artem,

Thanks for the proposal you made available at:
> On Tue, 2006-10-03 at 18:20 +0300, Artem Bityutskiy wrote:
> > http://www.infradead.org/~dedekind/fix_and_rewrite_gluebi_and_co/

Here is my view on the changes you sent:

The idea with the command line which solves the initialization order
issue looks very good to me. We should add a kernel config option to set
a default. In my case it would the MTD named "content" which
needs to be UBInized.

It is good, that the MTD emulation (gluebi) is now a part of UBI. I
think I won't miss the notifier mechanism, nor the additional
interfaces.

I was astonished that you managed to support JFFS2/UBI with so few 
changes to the original JFFS2 code. I saw that you introduced a new
mtd->type of MTD_UBIVOLUME for the MTDs created be UBI to accomplish
this.

Nevertheless the original JFFS2/UBI support from Joern had some
important advantages which we should keep:

The gluebi-MTD supported the put_block() operation to pass blocks
back to the UBI layer. One reason for doing it was to eliminate the need
for JFFS2 to care about erasing blocks (Joern, Thomas if there were
more, please comment). If JFFS2 needs a block, it gets one from UBI, if
it wants to get rid of it, it passes it back to UBI, which can do now to
whatever is best e.g. apply wearleveling mechanisms. UBI knows best what
to do with blocks which are due to erasure. However this mechanism
introduced some more changes to JFFS2 at all the spots where blocks were
to be deleted.

The put_block() feature of an MTD is of general nature, I think. We
should probably not ty it to UBI. If an MTD has this feature JFFS2 can
exploit it in the way Joern showed in his example. Let's keep it, but
let us remove any UBI naming in that code:

	if (jffs2_has_put_block(c)) {
		jffs2_put_block(c, jeb);
		...

Let's do some discussion on the details in the chat. After we are all on
the same page, I will go ahead and change my reference platform code to
do the testing, before we officially publish the modfied changes in the
ubi-2.6.git.

Frank

  parent reply	other threads:[~2006-10-06  7:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-03 15:20 UBI fixes Artem Bityutskiy
2006-10-04 10:14 ` Artem Bityutskiy
2006-10-04 10:52   ` Artem Bityutskiy
2006-10-06  7:56   ` Frank Haverkamp [this message]
2006-10-06  8:29     ` Artem Bityutskiy

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=1160121379.5460.29.camel@localhost.localdomain \
    --to=f.haverkamp@web.de \
    --cc=dedekind@infradead.org \
    --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