[PATCH/RFC] MTD: Striping layer core

[Nicolas Pitre]

On Fri, 31 Mar 2006, Artem B. Bityutskiy wrote:

> On Fri, 2006-03-31 at 13:40 +0200, Jörn Engel wrote:
> > Right now, we have code like
> > 
> > #define jffs2_can_mark_obsolete(c) ((c->mtd->type == MTD_NORFLASH && !(c->mtd->flags & MTD_ECC)) || c->mtd->type == MTD_RAM)
> > 
> > I guess we can both agree that it is far from optimal.  And my take
> > would be to replace it with
> > 
> > #define jffs2_can_mark_obsolete(c) (c->mtd->flags & MTD_CAN_MARK_OBSOLETE)
> > 
> Add an c->flags field to the per-JFFS2 structure. Initialize it on mount
> properly. Then
> 
> #define jffs2_can_mark_obsolete(c) (c->flags & JFFS2_CAN_MARK_OBSOLETE)
> 
> Don't try to jam this to MTD please.

Artem, you have it backward.

What needs to be exported is a flash _capability_, not a flash type.

We don't care a single whit if the flash is NOR or NAND or bufferedNOR 
or any other bastardized type that will come up in the future.

What MTD users like JFFS2 or mtdchar needs to know is:

 - what is the minimum write size

 - what is the optimal write size

 - can individual bits be cleared

 - can individual bits be set

 - what the OOB size is

etc.  That is sensible information to have and that what the actual code 
implementation in JFFS2 cares about.

Otherwise, what do you do with, say, Sibley flash?  Sibley is NOR but 
not like the traditional definition of NOR flash.  It could be seen like 
buffered NOR but not exactly.  It could be handled like NAND but without 
any OOB data.  So what is the solution: adding yet one more flash type?  
Alternately it could be described fully in terms of the above 
_capabilities_ which is what matters in the end.


Nicolas