[PATCH/RFC] MTD: Striping layer core

Nicolas Pitre nico at cam.org
Fri Mar 31 11:49:53 EST 2006


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

> Alexander Belyakov wrote:
> > > Well, probably this is a perversion and is not needed in reality, but
> > > still. I conceive it like this. Yo have 2 flashes. You as usually,
> > > calculate the resulting eraseblock size. You see at the minimal I/O unit
> > > size of both flashes and similarly calculate the resulting minimal I/O
> > > size. So that's it. You'll end up with a though perverted, but still a
> > > striped MTD device.
> > 
> > First problem in case of striping NOR and NAND is a question about type of
> > striped device. Should we report it as NOR or as NAND. I believe it is
> > important for clients to know about that. Imagine, for example, device
> > reported as NAND behaves as NOR or vice versa. Another problem is a
> > difference in operation speed. Apparently you won't get any performance
> > gain. These are only top of iceberg. Note that even plain and simple
> > mtdconcat is not supposed to work with flashes of different types.
> 
> Good question. I think you could report this is a striped device (introducing
> an MTD_STRIPED option). Also you may provide a stripe_get_info(struct mtd_info
> *mtd) function which will return a struct stripe_info object describing this
> striped device, including the components it consists of.

But... before going that far, is this something that really makes sense 
in practice?

IMHO striping NOR and NAND together simply makes no sense.  NOR and NAND 
are fundamentally different things when it comes to writing to them, and 
apart from evaluation boards where every possible peripheral can be 
found you rarely will find both NOR and NAND in the same real life 
design.

So why bother?


Nicolas




More information about the linux-mtd mailing list