Support of removable MTD devices and other advanced features (follow-up from lkml)

[Jörn Engel]

On Wed, 21 May 2008 18:30:44 -0700, Alex Dubov wrote:
> 
> > So here is a lightly modified version of your mtd_request bits.  Apart
> > from reformatting and adding some documentation, the changes are:
> > 
> > - No flag for MTD_DATA, as this should be the default
> 
> # Nope. What about the case where you only want to read the oob (block scan) or
> have no data to transfer (block invalidate)? Of course, this "flags" field may
> be omitted outright, and the drivers could rely on error returned from
> mtd_get_buf/mtd_get_oob, but this may turn out awkward.

Fair enough.

> # You have to retain logical block address when using FTLs. This also makes
> "struct mtd_address" confusing - the offset applies the same both to physical
> and logical block. User level driver may want to fill in only logical block
> address + offset, FTL will put in the actual physical block.

But nothing below the FTL should ever know about a logical block at all.
Why pass it on?

> # And it's not clear to me why would you need pointer to data in the request
> struct. Data is delivered through the additional (quite often more than one)
> call to mtd_get_buf. I think, it's imperative to support fragmented buffers -
> block device often submits requests that are larger than eraseblock (can be
> read/written in one go) but fragmented across several memory buffers.

We can replace the data pointer with a struct bio_vec.  In fact, I am
wondering whether we could just use a struct bio instead of struct
mtd_request.

Jörn

-- 
Mundie uses a textbook tactic of manipulation: start with some
reasonable talk, and lead the audience to an unreasonable conclusion.
-- Bruce Perens