On Tuesday 02 August 2005 04:02
manningc2@actrix.gen.nz wrote:
> AT present, YAFFS2 uses 64-bit times for WinCE and 32-bits for
> other stuff.
>
> IMHO it would be best to use 64 bit for everything internally
> and use some sort of fudge factor for 2.4 kernel.
>
> Benefits:
> 1) Get the feature in OSs that support it.
> 2) Get rid of ugly #ifdef WINCE stuff in the code.
>
> Unless there is a noise to the negative, I'll do this in two
> days or so.

Here's an opinion... and this is just for your consideration,
I understand your motive for change and it looks like you are
only considering the in-memory timestamps, not those in flash,
is that right?

Long-term stability in the on-media data format is very 
desireable. I'm sure you have given a lot of thought to what's 
actually layed-down in flash.  We have (user) data in NAND that 
*will* outlive the version of YAFFS/MTD code that created it.
We will need to access data in NAND in whatever format it happens 
to be in.  It is not easy to save, reformat and reinstall data 
from NAND in an isolated embedded system where there is more 
data than free RAM.

We recently hit an issue with the ECC byte ordering. We have 
thousands of units in the field that run with the original YAFFS 
code on small-page NAND, now we have moved to the YAFFS2 code 
base (to support large-page devices) and have found that the 
MTD-based ECC has different on-NAND byte ordering when running 
in YAFFS1 mode.  Of course we have fixed this with a simple 
change to the code which we will have to maintain.  Some users 
have a real need to support older formats 'forever', and it 
would be very nice if YAFFS could be built to support its older 
formats without too much hacking.

If you are considering a change to the on-NAND format, perhaps 
adding a format version identifier somewhere (c.f. disk 
superblock) would aid the management of variant NAND formats, so 
newer YAFFS/MTD code can be deterministic and figure out what to 
do when it meets old NAND data.  The same layering technique you 
use with the internal/external tags format conversion could be 
applied to Yaffs objects too -- treat it like a network protocol 
with an internal representation and a separate on-the-wire 
(on-the-nand) representation.

-imcd