[ECOS] Re: RE : RE : [ECOS] Is JFFS2 thread-safe?
Thu Nov 27 10:24:00 GMT 2003
On Thu, 2003-11-27 at 11:03 +0100, Vincent Catros wrote:
> Thanks David,
> This is clear for me now.
In answer to your earlier question about chmod/chown -- they're trivial
to implement. JFFS2 needs to keep track of modes and ownership
internally (in its struct _inode) so that it doesn't corrupt them when
modifying a file system shared with Linux. They should already be
returned by stat(), and the only barrier to allowing you to _change_
modes or ownership from your application is the lack of suitable API for
such purpose. I don't really want to abuse jffs2_setinfo().
The TODO list for JFFS2/eCos is now as follows. I'm hoping someone with
more eCos-clue will pick up some of this:
- Fill in the skeleton gcthread.c so it actually does something.
- Check and possibly fix locking of icache mangling in fs-ecos.c
- Check that os-ecos.h defines 'spin_lock()' to something appropriate.
- Fix unmount of root file system after chdir().
- Fix atomicity of renames. Why was the unlink added before rename?
- Further cleanup -- should the functions in dir-ecos.c take 'struct
dirsearch' instead of various components thereof, or should each of
those functions just be moved inside its only caller in fs-ecos.c?
- Improve mount time by using pointer directly into flash chip instead
of jffs2_flash_read() for the initial scan -- look at the #ifdef
__ECOS bit in scan.c for details.
- Reduce memory usage. There are fields marked for possible removal in
struct _inode, and there's the __totlen field in struct
jffs2_raw_node_ref as discussed recently.
Sort of separate, and I have a hacked-up mostly working version already:
- Make fileio package not gratuitously include kernel header files.
- Add up RedBoot fileio support so RedBoot can read/write JFFS2.
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
More information about the Ecos-discuss