I support Luc's suggestion below, but the only caveat is that existing WinCE 
stuff would get broken. This might or might not be an issue for WinCE folks, 
but I hunch the standard WinCE operating model is that if you update your OS 
you re-nuke your flash storage too, making this a non-issue.



On Wednesday 03 August 2005 09:51, Luc Van Oostenryck wrote:
> Charles Manning wrote:
> > I have tried to only modify stuff by addition, ie by whittling at the
> > roomToGrow.
> >
> > I think the above will be OK, but your comments would be appreciated.
> >
> > <snip>
> >
> > -- CHarles
>
> Since your proposition only use reserved space and the nand (RoomToGrow),
> and the 0xFFFFFFFF pattern is in invalid number of nanoseconds;
> we can have perfect compatibility, so I don't why we shoulnd't do it.
>
> The only reason I can see against this is that will leave only 16 reserved
> bytes, can it be that one day we would whish to use more than this for a
> more important thing?
>
>
> We can save 12 bytes, if we leave the actual storage for yaffs1
> compatibility and to store the seconds for yaffs2 and use 12 bytes from
> RommToGrow to only store the nanoseconds for yaffs2. Thus the area should
> become:
> 	__u32 yst_uid;   // user ID of owner
> 	__u32 yst_gid;    // group ID of owner
> 	__u32 yst_atime_sec;/ time of last access
> 	__u32 yst_mtime_sec;/ time of last modification
> 	__u32 yst_ctime_sec;/ time of last change
>
>
> <snip>
>
> 	__u32 yst_ctime_nsec;	// don't use the value if it is 0xFFFFFFFF
> 	__u32 yst_atime_nsec;	//    -> compatibility with yaffs1
> 	__u32 yst_mtime_nsec;
> 	__u32 roomToGrow[7];
>
>
>
> Luc