[PATCH,RFC] [MTD] replace MTD_NORFLASH with MTD_GENERIC_TYPE

[Nicolas Pitre]

On Wed, 31 May 2006, Artem B. Bityutskiy wrote:

> 1. Having an mtd->field field and capabilities flags a bad idea. Why?
> 
> 1a: Who initializes this mtd->flags field?

The chip driver providing anMTD interface to said chip.

> If I want to add 20 new
> capabilities, how many places do I have to change? As many as there are
> drivers in MTD? Insane.

Don't be ridiculous.  There is no way you can find 20 capabilities total 
for a generic MTD interface.

> 2a. In general, the capabilities thing is application-dependent. And it
> must stay in application's area, not deep in drivers.

Not true.  The capabilities are function of the hardware not the 
application.

> 3a: If I'm a user of MTD, and I want to add 20 new capability, do I have
> to change MTD itself? It's not my business to do this.

If you want to add new capabilities, you only have to care about users 
of those capabilities and of course users that worked without them 
before will just continue to work if they ignore them.

> 4a. How wide is the mtd->flags field? 32 bits? So, you restrict me by 32
> capabilities? And if I need more, I have to combine the existing ones?
> Why is it better then using mtd->type?

Who said capabilities have to be only single bits?

And even if the capability field as you insist to see it has only 32 
bits, what prevents you from extending it in the unlikely event more 
bits might be needed?

> So, this is not an extensible solution.

Artem you're more brilliant than that.

> 2. OK, what do you offer instead (the question nobody asked yet)?
> 
> Forget about mtd->flags. Leave alone mtd->type. Add an
> include/linux/mtd/flash_capabilities.h header which looks like this:
> 
> /* If the flash allows to clear individual bits */
> #define mtd_can_clear_bits(mtd) (mtd->type == MTD_NORFLASH)
> /* If the goat may be milked */
> #define mtd_can_milk_a_goat(mtd) (bah)
> ....
> etc.
> 
> So, you have your set of capabilities. You use this header in JFFS2 and
> clean it up. Your task is solved.

And the runtime code is both larger and slower.  And the source is 
even more obfuscated.  Isn't that great?


Nicolas