UBI fixes

UBI fixes

[Artem Bityutskiy]

Hello Frank,

I've fixed the stuff which was recently committed. Well, I basically
re-wrote gluebi and made it part of UBI. There is a corresponding
configure option (see Kconfig) for this. Now we don't need this
unpleasant notifiers stuff.

I also made some minor fixes, and supposedly fixed the debugging log
problems you had.

There are many patches, so I don't attach them.

You can find my quilt "patches" directory at
http://www.infradead.org/~dedekind/fix_and_rewrite_gluebi_and_co/

You can also find them in my git tree at
git://git.infradead.org/~dedekind/public_git/dedekind-ubi-2.6.git

or take a look in git-web at
http://git.infradead.org/?p=users/dedekind/dedekind-ubi-2.6.git;a=summary

Artem.

-- 
Best Regards,
Artem Bityutskiy (Битюцкий Артём)

Re: UBI fixes

[Artem Bityutskiy]

On Tue, 2006-10-03 at 18:20 +0300, Artem Bityutskiy wrote:
> There are many patches, so I don't attach them.
> 
> You can find my quilt "patches" directory at
> http://www.infradead.org/~dedekind/fix_and_rewrite_gluebi_and_co/
> 
> You can also find them in my git tree at
> git://git.infradead.org/~dedekind/public_git/dedekind-ubi-2.6.git
> 
> or take a look in git-web at
> http://git.infradead.org/?p=users/dedekind/dedekind-ubi-2.6.git;a=summary
> 

I've also solved your problem when UBI attach functions are called
*before* UBI is initialized.

The solution is trivial: dispense with the nasty idea to call UBI attach
functions from MTD drivers. Of course MTD drivers are initialized
*before* UBI, and then they call the ubi_attach_mtd_dev() function,
while UBI have *not* been initialized yet, and this causes problems.

Instead, use kernel boot arguments. Add a 

ubi.mtd_devs=<list of MTD devices to attach>

argument and enjoy. Everything just works.

You can specify UBI device names and numbers there. For example:

ubi.mtd_devs=0,"storage","NOR_flash",6

means attach mtd0, mtd6, and MTD devices with names "storage" and
"NOR_flash".

The patches may be found at the same place. Please, try them on your
system.


-- 
Best Regards,
Artem Bityutskiy (Битюцкий Артём)

Re: UBI fixes

[Artem Bityutskiy]

On Wed, 2006-10-04 at 13:14 +0300, Artem Bityutskiy wrote:
> ubi.mtd_devs=0,"storage","NOR_flash",6

Err, sorry, no quotes:

ubi.mtd_devs=0,storage,NOR_flash,6

-- 
Best Regards,
Artem Bityutskiy (Битюцкий Артём)

Re: UBI fixes

[Frank Haverkamp]

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

Re: UBI fixes

[Artem Bityutskiy]

On Fri, 2006-10-06 at 09:56 +0200, Frank Haverkamp wrote:
> 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.

Yes, this is not difficult.

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

My opinion is:

1. If you keep this - then whole idea of gluebi makes zero sense. Then
just port JFFS2 to UBI native interface. Chose one of the roads - either
transparent compatibility (gluebi) or native interface. It is not wice
to choose a mix of them.

2. All this put_block() does introduce some optimizations. But it is
minor. It does not worth the crap we introduce into MTD and JFFS2. It
really does not worth it.

3. If you really want these improvements, and you *even* persuade dwmw2
to accept these hacks into JFFS2, and tglx to accept this in MTD - fine.
This won't add more "odd" things to UBI - and I'm happy. Although I
don't like the idea.

> 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:

OK, I understand, although I still believe it doesn't worth it. I have
quite a large experience of digging JFFS2. And I assure you - it is
complex enough already.

-- 
Best Regards,
Artem Bityutskiy (Битюцкий Артём)