[PATCH/RFC] MTD: Striping layer core
Nicolas Pitre
nico at cam.org
Fri Mar 31 11:59:23 EST 2006
On Fri, 31 Mar 2006, Artem B. Bityutskiy wrote:
> On Fri, 2006-03-31 at 12:17 +0400, Alexander Belyakov wrote:
> > In that case clients should be aware of using striped devices and
> > provide special support for them. The one of the ideas of the suggested
> > solution is to hide striping internals from the client providing generic
> > mtd device (just with somewhat increased performance).
>
> I think you are one more guy who hit on the not generic enough
> interface.
>
> Indeed, on the one hand, you want to inform the type of flash used. If
> this is NAND, people have to use NAND-specific stuff like
> mtd->write_ecc. If this is NOR, they have to use NOR-related stuff like
> mtd->write, mtd->point and so on.
>
> On the other hand, you still want to inform users that this is a striped
> MTD device. They may want to know this.
>
> And the best thing you can do is not to adopt yourself to far too old
> MTD interface, which is like this for historical reasons, but to make a
> revolution in the MTD interface itself.
>
> By revolution I mean:
>
> 1. To invent a common generic flash model.
> 2. To make MTD interface generic.
> 3. To fix existing users. Well, I would say fixing JFFS2 may be enough.
>
> This is a big piece of work, but it is what I consider a professional
> approach.
I'm sorry but I must disagree with your assertion above.
Yes the MTD interface might need a big revamp... but why would that be
related to stripe at all?
Why would a striped MTD device be different from, say, a partitioned MTD
device?
Part of having a professional approach is _not_ to mix everything up
together. And to that effect I don't see anything at the interface
level even in its current form that would prevent an MTD stripe module
from playing nicely with the rest of the users, just like mtd partitions
or mtdconcat.
Nicolas
More information about the linux-mtd
mailing list