From: Charles Manning <manningc2@actrix.gen.nz>
To: linux-mtd@lists.infradead.org
Cc: "Artem B. Bityutskiy" <dedekind@yandex.ru>
Subject: Re: NAND simulator
Date: Sun, 11 Dec 2005 11:28:34 +1300 [thread overview]
Message-ID: <200512111128.34835.manningc2@actrix.gen.nz> (raw)
In-Reply-To: <439821F4.7010403@yandex.ru>
On Friday 09 December 2005 01:07, Artem B. Bityutskiy wrote:
> Hello,
>
> I'm going to rework NAND simulator (nandsim, drivers/mtd/nand/nandsim.c)
> to add the following functionality:
>
> 1. Emulation of devices larger then 128MB
Yes please.
> 2. Possibility to manually specify any page size/eraseblock size/flash
> size.
Double yes please! The current way of doing things is very hard to use
effectively and you need to hack quite a few places to make a useful
simulation.
The current approach of simulating a physical device is probably good for
testing nand.c, but it is not so great for testing file systems. If I want to
test, for example, a file system on an arrangement of say 350MB then I have
to go through some crazy steps like making up a fake device id and fake the
chip id to give what I want. I think a more direct approach of just inserting
a set of size parameters is far better.
>
> I am going to remove flash delays emulation as it appears to be
> unusable. No objections?
Yup, I don't see much point in trying to simulate the timing. In reality
nandsim is only really there for algorithmic testing and not time
simulations.
>
> If there are some additional offers, please, provide.
I assume you mean requests :-). If so, I have a question/request.
Can nandsim simulate storage larger than physical RAM (just swapping out) or
would this need special support (eg. add some block device support? We're
getting people in YAFFSland who are working with 8Gbytes of flash (and it
will only get bigger!) and I expect you'd want large emulations to stress
JFFS3. Being able to simulate areas up to, say, 16Gbytes for now would be a
nice thing.
A way of simulating a failure (bit flip, write error) would also be handy for
testing fs and ecc error handling.
Tell me if you need a guinea pig.
-- Charles
next prev parent reply other threads:[~2005-12-10 22:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-08 12:07 NAND simulator Artem B. Bityutskiy
2005-12-10 22:28 ` Charles Manning [this message]
2005-12-11 13:46 ` Artem B. Bityutskiy
2005-12-11 17:53 ` Charles Manning
2005-12-11 22:07 ` Josh Boyer
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=200512111128.34835.manningc2@actrix.gen.nz \
--to=manningc2@actrix.gen.nz \
--cc=dedekind@yandex.ru \
--cc=linux-mtd@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox