Re: [PATCH 2/2] ubi-utils: ubinize: Add fastmap suport to image creation

[Richard Weinberger <richard@nod.at>]

Am 18.03.2015 um 13:41 schrieb Tanya Brokhman:
> (thinking out-loud, trying not to reveal our flasher details)
> UBI aware flasher has to:
> 1. scan partition and collect ec values
> 2. for each PEB of the image: update the ec_header, erase PEB and flash the image
> 3. for remaining empty PEBs erase and write ec_heaser
> 
> For generating FM in flasher we need to update #2 and while flashing the image construct the FM data in memory. (what PEB, for what volume etc). this is O(1)
> 
> When we have the layout in memory we need to construct the actual FM data => go over all lists => O(number of dev PEBs) => probably can be neglected as well.
> 
> Ok, I take it back: run time wont be effected. What will be effected is memory consumption.

Yeah, but a smart flasher would of course not keep the whole image in memory.

> If I remember correctly, when we discussed this whole idea a while back you mentioned that a lot of users use their own proprietary flasher. So from your experience: you think
> users will prefer to have a libfastmap and not ubinize enhancement?
> Maybe implementing libfastmap to be added to any flasher isn't such a bad idea. Then the whole "ubi awareness" can be implemented there.
> I wasn't aware of the fact that ubinize is skipped. Is this common?

I've seen that more than once. Customers tend to use their own non-trivial tools. ;)
If we implement libfastmap ubinize could also use it (plus a big fat warning that you'll need a fastmap aware flasher).

Thanks,
//richard