Re: how to use jff2 on UBI layer?

["Artem B. Bityutskiy" <dedekind@yandex.ru>]

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

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.

> It seems somewhat superfluous to add a generalized I/O layer to jffs2.
> It just doesn't sit right with me.

---------
I have nothing against gluebi as soon as:

1. It works. And AFAICS, we cannot make it all right *for months*.
2. It does not include a lot of stuff like:
	if (jffs2_is_ubi(c)) {doh()}
scattered across JFFS2. Instead, JFFS2 must have zero changes in case of 
gluebi.

Otherwise, gluebi makes no sense, IMO.

---------

"Something superfluous" are just some subjective words. The objective 
things are

1. JFFS2 just works with my patch over UBI: mount -t jffs2 ubi0 
/mnt/jffs2 - and you're happy. No need to create strange "fake" MTD devices.

2. There is no half-sane (from MTD's POW!) mtd->put_block() addition in 
my patch.

3. After all - I see nothing bad in this "superfluous" thing. It just 
adds better modularization. Moreover, now I can remove crap like

#ifdef __ECOS
mtd->point()
#endif

as well as eCos erasure.

just because I can implement eCos I/O in io.c.


-- 
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.