State of UBI

[dedekind]

>> 1. "double page writes on NAND" - it needs MTD changes and zero UBI changes.
>
>I'll politely disagree here.  UBI _does_ need this on NAND to be
>really usable.  Otherwise you eat 2 pages per block for UBI metadata,
>and that is quite a bit of overhead for a handful of bytes in the
>structures.
Josh, I politely ask you to read what I said once more, sorry :-).

I didn't say the "double page" stuff is not needed. I agree that it *is*
needed, and is very important!

What I said is that this feature requires *zero changes in UBI code*. 
It requires changes in *MTD* code. So this is why I said it
does not really relate to UBI itself, it relates to what I called
"about UBI" in the previous mail. :-) See what I mean?

>> 2. Better UBI utilities as I find the current ones not ideal.
>What do you find lacking or not ideal?  I'm just curious.

I dislike that the utilities accept UBI device number instead of UBI
character device name. And they internally form the UBI device name
using hardcoded "/dev/ubi%d" pattern. It it insane. I may want to name
my UBI devices differently.

I'm partially guilty in this because I started the libubi library with
this insane feature. But I wrote it for my tests and didn't mean to
use it as a generic library. Then I created a new sane version of ubilib
but people had written most of the UBI utilities using the old insane one
by that time...

Also, the ubimkvol utility works only for ubi0 device and does not
work for ubi1 device. I did not dig why.

Artem.