public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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

  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