Re: how to use jff2 on UBI layer?

[Frank Haverkamp <haver@vnet.ibm.com>]

Hi,

On Mon, 2006-07-31 at 11:43 +0400, Artem B. Bityutskiy wrote:
> Artem B. Bityutskiy wrote:
> 
> >> For what it's worth, I personally prefer the gluebi approach.  Or at
> >> least it's design.  I don't see why UBI cannot add_mtd_device for
> >> every volume that is found within the overall MTD given to it.

UBI was and is intended to smoothly integrate in Davids MTD
architecture. Therefor I strongly agree with Josh (and Joern) that an
MTD device should be created for each UBI volume.

This would help to plug-into the existing architecture nicer and it
would make it easier for others to combine the UBI layer with existing
code. The UBI user should not be forced to add a comatibility layer
underneath his existing software to have UBI support. If he discovers
later on that he gets a benefit from using UBI directly, it is fine, but
not in the first place.

> > 
> > Just because it's strange from the design POV. UBI != MTD device 
> > semantically => any attempt to access UBI as MTD device is a dirty hack.

This is only the current UBI implementation. The UBI design would also
be implementable as MTD device itself. I think it is not "a dirty hack".

> 
> Err, I have to refine my position Of course, the idea itself is OK - it 
> is useful to make MTD-oriented software work on top of UBI. But it is 
> still a hack, just because UBI != MTD subset, strictly speaking.

You say "the idea itself is OK" and in the next sentence you call it
"still a hack". What is it now in your eyes "OK" or "a hack"?

> 
> But again, see in my previous mail, JFFS2's gluebi port has little to do 
> with a transparent MTD emulation layer. At lease the gluebi I'm aware of.
> 

The gluebi implementation I have seen, seems to me the best compromise
to allow UBI being something different than an MTD, but still providing
the integration of UBI into the MTD framework, which from my perspective
the best way to advertise UBI.

It is good that you came up with your JFFS2/UBI integration proposal,
since it shows, how one could use UBI volumes intead of using MTDs.

I reviewed it, and came to the conclusion, that adding a full new
io-layer to JFFS2 is currently overkill. The situation might be
different if David thinks that your io-layer is usefull for his further
plans with JFFS2. But until I have seen such a statement from him, I
would rather like to see Joerns approach with the MTDs being created by
his gluebi-code in the ubi-2.6.git. I think it is more usefull to have
those MTDs, than adding new io-layers to any other code, which may want
to use the UBI feaures, e.g. cramfs, squashfs, maybe even VFAT stuff.

MTD is already an abstraction and enables layering. Adding more and
especially unique layers is from my view not the best choice. 

If you think that MTD as abstraction layer is not sufficient or ugly, it
is a completely different discussion which should be done with David
directly. Please do not use UBI to try to introduce your own abstraction
style and layers. Instead talk to David about MTD2 or similar.

Please also refer to http://www.faqs.org/rfcs/rfc1925.html (6a) which
was intended for the networking topic, but may also apply here.

Frank