MicroMonitor TFS & RTEMS

[Steve Strobel]

At 12:28 PM 9/28/2004 -0400, you 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!),
>> >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 

I just wanted to give a plug for MicroMonitor and TFS.  We are using TFS from within our RTEMS app using direct calls to MicroMonitor rather than the C library API.  We can update firmware by making ftpd store a new (stripped and compressed) elf file in TFS (which MicroMonitor loads into memory and runs on startup).  We store multiple device configurations as files in TFS as well.  To provide persistent variable storage, we serialize the data and use MicroMonitor's flash drivers to store it in dedicated flash sectors (bypassing TFS).  That avoids the need to periodically defragment, but locks us into a fixed number of flash sectors for that storage.  Being able to access those files using the C API will be really nice, as it may avoid the need to modify existing code (like we did with ftpd) to save files into TFS.

Steve



---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:steve at link-comm.com