= File Systems =

= RTEMS File Systems =




RTEMS provides support for file systems. The POSIX standard and the Single Unix Specification define a range of calls that allow applications to access and control files on a file system. Embedded systems have evolved to allow support for file systems and files. Files are a well understood means of managing various forms of data on desktop and server type system. The same can also applies to embedded system with some obvious constraints.

Embedded applications benefits of using files are:

# Standardized means of accessing and controlling files.
# Portable applications.
# Support for 3rd party type applications, eg web servers.
# Simplified remote access to networked data.

The downside is a larger embedded foot print for code and data, and file system accesses are typically not real-time.

The code and data size depends on the file system being used. A simple TFTP type file system has a small foot print but does require a networking stack. A block device file system such as the FAT file system has the overhead of implementing a full file system.

Real-time use of a file system is a complex issue and beyond the scope of this topic. Dr Joel Sherrill's PHD thesis studied real-time file-systems and concluded the whole system from application to driver needs to be considered when handling real-time data. Typically an application would read configuration type data into memory rather than use the file-system directly.

RTEMS supports the following file systems:

# IMFS or In Memory File System
# MiniIMFS Minimal In Memory File System
# TFTP or Trivial File Transfer Protocol File System
# FTP or File Transfer Protocol File System
# NFS or Network File System
# FAT or MSDOS File System

The root file system is always the IMFS file system. It provides a small footprint means to allow device driver nodes to be located in the file system, and to mount other file systems. There is also the MiniIMFS which is smaller in size with less features.
= IMFS File System =


The In Memory File Systems is always root file system and uses the standard C library heap for storage. The file system will only consume memory for the nodes and files it holds and releases memory back to the heap when no longer used. The design of this file systems is full standards support, small foot print and lower memory overhead. The file system is also fast for small sized files and directories. This suites hold small configuration files and device driver nodes.

This file system is volatile. After an application restart you will need to construct its contents. RTEMS provides some supporting calls for this plus there is the ability to tar files into it.

The file system is ideally suited to holding file typically found in <tt>/etc</tt> or <tt>/dev</tt> on a Unix system. The RTEMS networking stack has been taken from FreeBSD and supports file such as <tt>/etc/hosts</tt> and <tt>/etc/resolv.conf</tt>. It is better to provide application support for DNS resolution via <tt>/etc/resolv.conf</tt> than the proprietary RTEMS calls added to the networking code. RTEMS supports the standard Unix type driver interface. You can register a driver with RTEMS and place a node in the file system that maps to that driver. The Unix standard major and minor device numbers are supported. Device nodes provide a standard means of access a device. For example a specific target BSP may provide a termios serial (UART) driver node called <tt>/dev/cfuart0</tt> which is named after the hardware yet an application may like a more logical name such as <tt>/dev/ttyS0</tt>. A simple solution is to create a symbolic link from <tt>/dev/cfuart0</tt> to <tt>/dev/ttyS0</tt>. The application is now isolated from hardware specifics via the file system.
= MiniIMFS File System =

= TFTP File System =

= FTP File System =

=  =NFS File System==


==MSDOS File System==