From: hujianyang <hujianyang@huawei.com>
To: Bill Pringlemeir <bpringlemeir@nbsps.com>
Cc: Richard Weinberger <richard.weinberger@gmail.com>,
linux-mtd <linux-mtd@lists.infradead.org>,
dedekind1@gmail.com
Subject: Re: [PATCH RFC v2] UBI: New ioctl() to support ubidump
Date: Mon, 4 Aug 2014 11:54:00 +0800 [thread overview]
Message-ID: <53DF03D8.6040504@huawei.com> (raw)
In-Reply-To: <87iomcrzo7.fsf@nbsps.com>
On 2014/8/1 23:35, Bill Pringlemeir wrote:
>
> 1. Allocate a 'pmap' array and a temporary 'sequence' array.
> 2. Initialize 'pmap' to -1.
> 3a. For each valid 'eb', get 'lnum' and 'sqnum' from vid header.
> b. if (pmap[lnum] == -1 || sequence[lnum] < sqnum)
> pmap[lnum] = eb, sequence[lnum] = sqnum;
>
I've researched the function ubi_scan() in libscan.c today and
found it's not easy to just add small changes to enable LEB->PEB
mapping table as we want.
There are two methods on enabling this functionality:
1) Add a mapping table in struct ubi_scan_info
2) Add some new parameters for function ubi_scan()
You know each MTD device may contain more than one UBI volume
and each volume should has a private mapping table. So it's not
easy to enable it in struct ubi_scan_info like method 1) because
we don't know the actual counts of volumes.
Further more, @sqnum is not enough for peb determining, we should
consider @on_copy flag for wear-leveling and atomic write. If
@on_copy flag is set, we need to read the whole leb and check CRC
to determine which peb is right. As this is a debugging tool, I
think printing all pebs have same lnum(of course in same volume)
is better. Now, we have to start thinking how to record this
stuff, that's a big problem.
In another way like method 2), we can add a new structure named
ubi_translate, put lnum and vol_id in it and returns a list or an
array contains the set of pebs which has a lnum equal to what we
set in translate struct. Original call like ubiformat set this
structure pointer to NULL and only ubidump use it. But if it's
better than writing a new function to do this stuff separately?
The code in ubi_scan is complicated now. Lnum translation is not
needed for ubiformat and the calculate of ec is not needed for
ubidump.
How about adding a new function to scan the whole MTD device and
just return a list contain all the pebs(mostly 1 or 2) in same
vol_id and same lnum?
in libscan.c
struct ubi_translate_info {
int lnum,
int vol_id,
int find, // counts of peb we find
int *array // dynamic or static(5? in size) array for
// recording peb num
};
int ubi_translate(struct ubi_translate_info *info /* or **info */)
{
// full scan the MTD device
while (...) {
read(ec);
// determine if it is a valid peb
...
read(vid);
if (vid->vol_id == info->vol_id &&
vid->lnum == info->lnum) {
// add to list @array
...
find++;
}
}
return err; // MTD is bad or something else
}
Just quick thought.
What's your opinion?
By the way, I have to say this separating of UBI and UBIFS makes
it really hard to read data from both sides.
next prev parent reply other threads:[~2014-08-04 3:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-29 9:20 [PATCH RFC v2] ubi-utils: Introduce a utility ubidump hujianyang
2014-07-29 9:26 ` [PATCH RFC v2] UBI: New ioctl() to support ubidump hujianyang
2014-07-29 14:48 ` Bill Pringlemeir
2014-07-30 2:01 ` hujianyang
2014-07-30 15:53 ` Bill Pringlemeir
2014-07-31 3:01 ` hujianyang
2014-07-31 13:24 ` Artem Bityutskiy
2014-08-01 2:50 ` hujianyang
2014-08-01 7:30 ` Artem Bityutskiy
2014-08-01 10:10 ` hujianyang
2014-08-01 15:35 ` Bill Pringlemeir
2014-08-04 3:54 ` hujianyang [this message]
2014-08-05 21:10 ` Bill Pringlemeir
2014-07-31 13:25 ` Artem Bityutskiy
2014-07-29 16:37 ` Richard Weinberger
2014-07-30 2:19 ` hujianyang
2014-07-29 9:31 ` [PATCH 1/5] ubi-utils: Add libdump files hujianyang
2014-07-29 9:35 ` [PATCH 2/5] ubi-utils: Enable lnum2pnum ioctl in userspace hujianyang
2014-07-29 9:41 ` [PATCH 3/5] ubi-utils: Introduce ubidump hujianyang
2014-07-29 9:43 ` [PATCH 4/5] ubi-utils: Add ubifs-media.h hujianyang
2014-07-29 9:45 ` [PATCH 5/5] ubi-utils: Modified Makefile hujianyang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53DF03D8.6040504@huawei.com \
--to=hujianyang@huawei.com \
--cc=bpringlemeir@nbsps.com \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard.weinberger@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.