Support of removable MTD devices and other advanced features (follow-up from lkml)
joern at logfs.org
Thu May 22 11:10:51 EDT 2008
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.
> # 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
Mundie uses a textbook tactic of manipulation: start with some
reasonable talk, and lead the audience to an unreasonable conclusion.
-- Bruce Perens
More information about the linux-mtd