File Systems

{| border="0" cellpadding="5" cellspacing="0" align="right"

! style="background:#efefef;" | |}

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. You should contract Joel if you would like advise on this topic. 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 the 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

<i>Add details</i>

TFTP File System

The TFTP File System provides simplified file access and no file control type operations. The file system allows access to read and write files from a remote TFTP server. You can open and read a file or open and write a file. You cannot seek on the file or perform file control operations such as delete the file or list a directory. The file system is useful when a more complete networked file system such as NFS is not needed and you wish to copy files to the target or to read a configuration.

The TFTP client does not support the various TFTP options such as block size so the performance of this file system is slow due to the default 512 byte packet size used.

The file system addresses hosts by parsing the file's path under the mount point. For example if the TFTP file system is mounted under the default mount point of <tt>/TFTP/</tt> an open of a file <tt>/TFTP/10.10.10.1/readme.txt</tt> would attempt to read using the TFTP protocol the file <tt>readme.txt</tt> from the host <tt>10.10.10.1</tt>. The file name used in the TFTP read request would have the leading <tt>/</tt> removed.

FTP File System

<i>Add details</i>

NFS File System

RTEMS supports the NFS or Network File System. This is a full featured file system that provides the full range of file access and file control functions. The NFS code is currently outside the <tt>cpukit</tt> and it is hoped it will move into the <tt>cpukit</tt> in a future release.

MSDOS File System

RTEMS supports the MSDOS file system or the FAT (File Allocation Table) File System. This file system uses the block device library and the block device drivers to implement the file system.

<blockquote> {| border="1" cellpadding="5" cellspacing="0"

! style="background:#efefef;" | MSDOS File System

! align="center" | Block Devices

! align="center" | Block Device Drivers |} </blockquote>

The Block Devices layer provides a buffering and caching type function that improves the performance of the file system. It also provides a simplified driver interface. Any file system could use the Block Devices layer how-ever only the MSDOS file system does. The block devices supported are:

# ATA Disk Drives # RAM Disk # Flash Disk # Non-volatile Disk