[PATCH/RFC] MTD: Striping layer core
Artem B. Bityutskiy
dedekind at infradead.org
Sun Apr 2 08:11:17 EDT 2006
On Fri, 2006-03-31 at 12:14 -0500, Nicolas Pitre wrote:
> 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.
(/me kindly reminds that this is a sort of "theoretical" conversation,
the current reality is different. And this is a bit out of striping
My statement is: applications have the right to know (if they do really
want) which type of device (a striped thing, NAND, NOR, etc) the MTD
device represents. So, mtd_info has to provide this information anyway.
And mtd->type is an excellent field for this.
So, "We don't care a single whit if the flash is NOR or NAND or ...",
unless we really want to, right?
> 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
This is what I call "the MTD device model". We define a set of
operations and metrics, and then represent any flash using this model.
We don't care that we loose some particular/peculiar features of some
flash types. We are rough. But we are generic. And there is still a way
to make use of the peculiarities if there is such a need,
> - what the OOB size is
---- as mall off-topic note ----
One note about this. There is a trend to remove OOB support from MTD
info at all. Yo may want to read this thread:
> etc. That is sensible information to have and that what the actual code
> implementation in JFFS2 cares about.
Indeed, this is sensible information. Yes, this is very useful.
Let's think, how many features there are going to be. I think many. How
to technically add support of these features? Flags? - bad, as in case
of many features you'll have to have flags1, flags2 fields.
I emphasize, now I do not object against the features stuff. I offer a
way to technically implement them.
I still think the only device-dependent field in MTD has to be mtd->type
storing the type of flash. I offer to get rig of any "feature" flag, at
least because it is not clear how to maintain *potentially* very large
number of features.
But we still may implement a small distinct unit in MTD. This module
will return a set of features present for each particular MTD device. It
will use mtd->type for this. This is semantically the same, but
Please, look here:
> 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.
I offer to have mtd->type == MTD_SIBLEY_NOR. And add the knowledge about
Sibley to the "MTD feature unit".
Artem B. Bityutskiy,
More information about the linux-mtd