On Fri, 18 Apr 2008, Alex Dubov wrote:

First off, can you please use a mail client which does line breaks at
around 78 chars ?
 
quoted text
> As you understand, both smartmedia media and hosts follow certain
> spec (publicly available here:
> http://www.ssfdc.or.jp/spec/index_e.htm, basic registration
> required). xd card spec is almost identical, adding some cosmetic
> features and restrictions (such as prohibition of single page
> programming). This means, that smartmedia access protocol can be
> abstracted out in the reader-independent way. You can seen in the
> xd_card_blk.c that it can operate both completely dumb controllers,
> while taking protocol shortcuts (using host->caps) to accommodate
> smarter readers (the only feature currently not there is
> adapter-side page copy - it can be easily added under FBD_COPY
> clause in xd_card_trans_req). The backend itself (jmb38x_xd.c)
> should not concern itself with details of smartmedia spec, as it
> will directly lead to code duplication among backends.

That's all fine. Nobody asked for the backend to know about smartmedia
on FLASH format details. The MTD NAND FLASH layer does not care about
on FLASH data format at all. It provides merily access on the hardware
level.

I agree that your approach of making the SM/XD layer capable of
handling clever and dumb hardware adapters is a good one.

The point where I stringly disagree is that your implementation is
forcing people with dumb hardware (see drivers/mtd/nand/*) to
reimplement the (maybe already) existing drivers in order to make use
of the ssfdc format, which will not work with the following real world
example:

------------------
| NAND controller |----------| On board NAND
| with HW ECC     |
|                 |----------| SmartMedia Card
------------------

Having a separate driver infrastructure for clever controllers, which
provide only semi raw access to the FLASH chip is fine simply because
such controllers do not fit into the MTD layer.

quoted text
> I meant here the ability of user to look and modify CIS page, as
> well as look at the current block translation table.

Well, you probably do this with an iotctl anyway. So what's preventing
you to modify the mtd block layer to handle client private ioctls.

Also there is no real requirement to use the mtd block layer at all
for that. Putting your layer on top of the raw MTD device is fine IMO.

quoted text
> > Correct.  Erase() is the only callback-based function and every single
> > driver implements it synchronous anyway.  Improving this situation is
> > needed for mtd's own sake anyway.  Either that or replacing mtd with
> > something else, likely the block device code.
>
> Revamping the underlying architecture of mtd will break a lot of
> stuff in the process, doesn't it?

That's the best excuse I ever heard for not improving code which has
shortcomings.

Thanks,
	tglx
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/