[PATCH] mtd/ubi: recognize empty flash with errors as empty

[Artem Bityutskiy]

On Thu, 2010-04-29 at 21:23 +0200, Sebastian Andrzej Siewior wrote:
> * Artem Bityutskiy | 2010-04-29 12:42:29 [+0300]:
> 
> >> So I think the latter case is now broken. In fact I just copied some
> >> random things into my mtd partition and after attach & mkvol they were
> >> gone with no error.
> >
> >You mean UBI just attached your device? What would you expect it to do
> >when it sees that part of eraseblocks contain corrupted headers? ATM, it
> >just formats those eraseblocks. What would be your expectation?
> 
> Before the patch attaching a bootloader[0] partition would not work. Now
> it does.
> 
> >> So in case we want to support something other than UBI then we should
> >> probably add another error code in order to distinguish between read
> >> error and not a vald EC / VID header.
> >
> >If you feed UBI flash with no valid UBI headers, it will be refused, I
> >think.
> 
> It does not, not anymore. si->is_empty is only set if we find a valid EC
> header. Unknown data results now in UBI_IO_BAD_{EC|VID}_HDR is excluded
> from si->is_empty. Duh.
> 
> >I actually do not really see what is the use-case or scenario you want
> >UBI to handle better.
> 
> The first case was:
> - empty flash
> - a bad block which is not marked as such.
> 
> This is now fixed. However, not empty flash with non-UBI data will be
> now UBInized. Earlier, it was refused, you had to use flash_eraseall or
> ubiformat first.
> 
> In my optinion accidently attaching is not a problem in the field. It is
> only a problem if you are attaching by hand and you mix up the
> partitions.
> 
> The patch attached should fix this and flash with something not UBI
> will be refused again. It is compiled tested, don't have hw here right
> now.
> 
> [0] assumed that the bootloader does not start with 0xff within the
>     first few bytes.

Yeah, I see. I am not sure I like your patch because the process_eb()
function becomes even more twisted and unreadable. I'll think if we can
do this another way.

Basically, what I am thinking about is to stop playing with si->is_empty
in process_eb. Instead, make process_eb just account which blocks were
found. And at the end, when all blocks are scanned, look at the
situation, what were the blocks, and decide whether to go for formatting
or not.

I'll send you an e-mail later.

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