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

[Alex Dubov <oakad@yahoo.com>]

> > # 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?

Media class specific backend must know it, to populate media's oob structure.
TI's smartmedia adapter, for example, wants to know it itself (it has a
hardware register for it).

> 
> > # 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.
> 

Passing the whole struct bio is an overshoot for what we want to support. It
has plenty of functionality that to my opinion would never be supported by dumb
flash controllers.

I thought, something simple would be enough, as long as it can handle buffer
fragmentation and give the backend access to the actual struct page for mapping
operation. It doesn't matter if this is a scatterlist or bio_vec (they are
mostly the same). What's matter is an ability to obtain several chunks of the
buffer in some not too obtrusive way.

Host controller will get a buffer chunk, and set up a dma into it. When it
catches dma boundary event, it'll get another chunk, while still in the
interrupt handler (as much as needed). If controller happens to have a real sg
dma, it can call mtd_get_buf_sg several times in advance to populate the sg
table.

Controllers lacking dma capability can do exactly the same using mtd_get_buf.