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
(text/plain)