MicroMonitor TFS & RTEMS

[Ed Sutter]

> >All,
> >Last night I took Joel's advice (from a while ago) and used the
> >tftpDriver.c code as a model for integrating TFS into RTEMS as
> >a mountable FS.  I shamelessly reused a good portion of the
> >generic parts of the code in tftpDriver.c (in places simply
> >changing _tftp_ to _tfs_).  At first glance, it appears to be
> >working fine, and now I can access TFS files through RTEMS's FS.
> >
> >So, assuming there must be more to it (it just can't be that easy!),
> >what kind of limitations are imposed by this interface?  I see
> >there is a limited number of interfaces (no ioctl, fstat,
> >etc...), but I hope to eventually get that stuff working.
> >Are there any other "gotchas" I need to be aware of for
> >integrating TFS into RTEMS as a mountable FS?
> >
> I don't know TFS -

Quick description:
TFS (Tiny File System) is a major component in a boot monitor that I wrote
called MicroMonitor.  As a part of the monitor, it provides a very maintainable
(IMHO) platform for an embedded system.  TFS, to be honest, isn't really a
file system, rather it provides a power-safe means to organize on-board
flash into name space, but still allows the user to access the data at the
raw memory level.  The TFS API gives the appearance of an FS (read,
write, open, close, ctrl, stat, seek, etc...) but under the hood it's just
a glorified linked list, with code that deals with flash defragmentation
in a powersafe way.
 
> It's desirable to support directory lookup and fstat.
> Without directories, 'pwd' won't work.
> Existing software often also uses seek.

Ok, that sounds reasonable.  TFS doesn't have a directory heirarchy;
however, I think (?) it will be easy to fake this.  The fstat and seek
functionality is already in TFS's API, so that should easily hook into
RTEMS.

Thanks!
Ed