MicroMonitor TFS & RTEMS

[Joel Sherrill <joel@OARcorp.com>]

Ed Sutter wrote:
>>>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!),

Maybe it can be.  You already had the magic code -- all you had to
do it hook it to the RTEMS filesystem.  :)

Very cool.

>>>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?

Can you have more than one TFS filesystem in a system?

Do you need to consider concurrent access of the filesystem?
You might want to add a mutex on it.

Are there API differences between CPU families, MicroMonitor
versions, etc that need to be accounted for?

Of course, the filesystem code is typical of an open source
project -- severely  under documented.  So any documentation
or README is good.

And assuming you will submit it, we need to add it to the Wiki.

>>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.  

I think just providing a single directory view for "readdir()" would
be sufficient.

You should be able to lift at least the shell of this code from the 
IMFS.   See cpukit/libfs/src/imfs/*dir*.c

 > The fstat and seek
> functionality is already in TFS's API, so that should easily hook into
> RTEMS.

Ditto for this code.

The TFS sounds conceptually similar to the IMFS except that you wanted
organized


> Thanks!
> Ed


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985