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

[Alex Dubov]

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

> 
> enum mtd_command {
> 	MTD_READ,
> 	MTD_WRITE,
> 	MTD_ERASE,
> 	MTD_COPY,
> 	MTD_INVALIDATE
> };
> 
> /**
>  * @block_no:	physical eraseblock number
>  * @block_ofs:	offset within physical eraseblock
>  */
> struct mtd_address {
> 	u32	block_no;
> 	u32	block_ofs;
> };
> 
> #define MTD_FLAG_OOB	0x01
> /**
>  * @mtd:	underlying memory technology device
>  * @command:	read, write, erase, etc.
>  * @flags:	additional flags to modify commands
>  * @dst:	destination address
>  * @len:	length for read/write
>  * @src:	source address - only used for MTD_COPY
>  */
> struct mtd_request {
> 	struct mtd_device  *mtd;
> 	enum mtd_command   command;
> 	int		   flags;
>

        u32                log_block;

	struct mtd_address dst;

> 	u32		   len;

 	struct mtd_address src;
> };
> 

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

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


By the way, my bias toward block device emulation is caused by the obvious fact
that overwhelming majority of flash devices in existence are used as such, and
not without much success (I don't see many people complaining about their usb
sticks and mmc cards, and those may run linux inside one day).