Changes between Version 11 and Version 12 of Developer/FileSystems


Ignore:
Timestamp:
Sep 12, 2008, 5:56:10 PM (11 years ago)
Author:
Rsg
Comment:

/* IMFS File System */

Legend:

Unmodified
Added
Removed
Modified
  • Developer/FileSystems

    v11 v12  
    4444
    4545
    46 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.
     46The 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 suits small configuration files and device driver nodes.
    4747
    4848This 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.
    4949
    50 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.
     50The file system is ideally suited to holding files 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 files 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 to 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.
    5151= MiniIMFS File System =
    5252