On Wednesday 21 September 2005 17:55, Sergey Kubushyn wrote:
> Can you simply tell something like "When using its internal
> ECC YAFFS uses such and such MTD functions and expects that
> they would return the raw NAND data?" It would be very easy to
> fix those functions instead of trying to understand what YAFFS
> is trying to do and what MTD think of that?
This would be very helpful. I have invested more than a few days
myself working out the wrinkles with the yaffs/mtd interface.
And while doing this I had wished precisely this. A brief
statement on the functional requirements of MTD by yaffs. I now
know there are at least three use cases: original yaffs, yaffs2
code running in yaffs1 mode, and yaffs2 running yaffs2.
> I simply can't
> believe that it requires two years to fix a couple of
> functions in MTD. Name those functions and I'll fix them
> myself.
There are issues with all the functions that yaffs has to use to
talk to MTD, there are issues with read, read_oob, write,
write_oob, and block_markbad, isbad. Please take up your gripes
with the MTD crew and help make this a priority.
You have been beating-up on Yaffs which is unfortunate, because
Yaffs actually has a very simple and clear interface to the
underlying flash primitives. The MTD interfaces that are
exported are in some ways too high-level for yaffs needs and
unlike JFFS, which is maintained by the same crew that make
decisions about MTD -- Yaffs is an innocent third-party just
trying to get along.
Now, even if we had a concise functional description of Yaffs
requirements of MTD (and I do think that would be an excellent
step forward) you would still have to reverse-engineer the
functionality of a particular blend of MTD. So a concise
description of the MTD API functions would be good too. And I
don't mean some out-of-sync HOWTO or README. I would suggest
including it in the appropriate source files.
> What is "some mtds?" Are there many of them? I do only know
> one, that in the Linux kernel.
MTD does not have 'official' releases -- you may have a
particular snapshot in your kernel source, there are many other
snapshots. Most of us have a blend of MTD code retrieved from
CVS at various times, with patches and local mods applied.
The MTD crew no longer supports the 2.4 kernel base, so there's
a major disconnect there.
> Generic MTD utilities (nanddump, nandwrite etc.) do NOT have
> any problems getting anything they need from MTD. That means
> they DO know how to ask MTD layer for what they want.
These utilities have minimal functionality and are part of the
MTD code based - keeping them in-sync with the MTD driver code
should be a no-brainer. They operate at the ioctl syscall level
and have a relatively stable interface definition. They not
really comparable to an MTD API client like Yaffs.
> Then, when using a bare YAFFS, without NAND ECC and
> tools--just erase the flash, mount it and copy files to the
> mounted filesystem--you mean MTD somehow changes data it
> receives from yaffs when writing files and send back to yaffs
> when reading them?
Yes, it does 'change data' when handling the critical oob/spare
data. This region of each flash page is used for two distinct
purposes: (a) to hold the ECC data associated with the real user
data, and (b) to hold filesystem metadata, i.e. Yaffs tags etc.
These two sources of data have to be packed and unpacked from
the oob/spare area. With MTD's current API design the
packing/unpacking has to be done by MTD _if_ MTD is responsible
for ECC operations. This is the most unstable/buggy issue with
Yaffs/MTD interworking.
> I AM trying to be constructive.
I (now) think you are.
-imcd
(text/plain)