Re: [PATCH 6/7] New utility ubidump

[hujianyang <hujianyang@huawei.com>]

> 
> I started some thing like this.  The source is attached.  As really you
> only want 'read only' access, there is a minimal portion of the
> UBI/UbiFs code that is needed.  I think that only the 'ubi-media.h' is
> needed.  The Linux is high performance and handles read/write with
> different fault conditions.
> 
> If you write code for read-only/single thread I think it will be much
> more simple than the active UBI/UbiFS code in the Linux kernel.  I did
> not look at the UbiFS layer as much.  It is far more complex that UBI
> imho; of course, I just saw a little of the internal volumes and the
> fast map features.  However, fast map itself should not be needed for
> this utility.
> 
> For your use case of analysis in a running system, I think that reads of
> '/dev/mtd0ro', etc can be used.  This way recovery features can also be
> developed if we identified some inconsistency; Ie, it is not required to
> 'mount' the volume before analysis.
> 
> The attached source just scans an file image and create an leb/peb
> mapping.  I only used the 'ubi-media.h' as documentation.
> 
> Fwiw,
> Bill Pringlemeir.
>

Hi Bill,

I've read your code.  This code shows me a better way to get EC header
and VID header than my 'ioctl' design. Thanks~!

I think my former work started in a wrong way. Using MTD functionality
as yours seems better to develop a new utility we want.

So in the next step, I would like to resend a new patch set which just
read fs data by mtd_read(). I think a new ioctl is needed to translate
specified eraseblock num from lnum to pnum. I will not care about volume
table or fastmap this time. This patch set will not support dumping
image file(something like -f) either. As Artem said, we should do this
step by step.

Thanks for your advice. I will resend this utility soon and Cc to you.


Hu