[Yaffs] Re: mv problem

[ian at brightstareng.com]

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