mtd_info->size again (lengthy)

[Jamie Lokier]

Jörn Engel wrote:
> > May I suggest submit_mtdio?  One concept to one name, you know.
> > 
> > F means flash, sure.  But we don't call the devices /dev/flash0, /dev/flash1.
> > Nor do we call it the Flash subsystem.
> 
> I never liked the name "mtd".

Me neither.

> But mtdio is even worse.  Dude, what are you smoking? ;)

submit_fio suggests "file I/O" to me....  Even if I knew better, it
looks just that bit too much like submit_bio for something file-ish.

submit_mtd_request or async_mtd, then! :-)

> > > And while at it, replace the 32bit size with a 64bit blockno and 32bit
> > > offset.  Unless someone is stupid enough to create devices with 4G
> > > erasesize, that should last for a human lifetime or something close.
> > 
> > Although a single chip is unlikely to have 4GiB erasesize for a while,
> > a cluster of chips might, and it should be possible to represent them
> > as a single device.
> 
> When you have a cluster of chips, striping them and increasing writesize
> and erasesize (and having each bad block kill perfectly good blocks in
> the other stripes) may be the first idea you have.  But I hope it won't
> be the last.

I didn't say it's a _good_ idea!  Just that I won't be surprised when
someone produces hardware like that.  And, there will probably be a
reason you haven't thought of why they did it that way.

> Part of the reason for asynchronous interfaces is to make parallel chips
> work fast without striping them.  Or rather, make them work even faster
> than stripes.

And erasing simultaneous with streaming writes, let the CPU get on
with something else, etc.

What should the behaviour be with devices which block the CPU during
synchronous writes and erases?  Right now, you can be sure the
temporary CPU blockage (if there is one) happens when you request the
I/O.  If it's asynchronous, depending on how it's implemented, the CPU
could block at an unexpected time later.

-- Jamie