Changes between Version 31 and Version 32 of Developer/FileSystems


Ignore:
Timestamp:
04/13/15 14:17:49 (9 years ago)
Author:
Wendell P Silva
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Developer/FileSystems

    v31 v32  
    40401. Flash disk
    4141
    42 The specific file system sections provide details of using that file system in RTEMS. The {{{fileio</code> sample application in the {{{testsuite/samples</code> source code of RTEMS provides a good example of the various configurations needed for the various file systems. The {{{fileio</code> example make use of the RTEMS Shell commands. The shell provides a range of commands that can be used to mount, format, copy and delete files on a file system.
     42The specific file system sections provide details of using that file system in RTEMS. The {{{fileio}}} sample application in the {{{testsuite/samples}}} source code of RTEMS provides a good example of the various configurations needed for the various file systems. The {{{fileio}}} example make use of the RTEMS Shell commands. The shell provides a range of commands that can be used to mount, format, copy and delete files on a file system.
     43
    4344= IMFS File System =
    4445
     
    4849This 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.
    4950
    50 The 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.
     51The file system is ideally suited to holding files typically found in {{{/etc}}} or {{{/dev}}} on a Unix system. The RTEMS networking stack has been taken from FreeBSD and supports files such as {{{/etc/hosts}}} and {{{/etc/resolv.conf}}}. It is better to provide application support for DNS resolution via {{{/etc/resolv.conf}}} 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 {{{/dev/cfuart0}}} which is named after the hardware yet an application may like a more logical name such as {{{/dev/ttyS0}}}. A simple solution is to create a symbolic link from {{{/dev/cfuart0}}} to {{{/dev/ttyS0}}}. The application is now isolated from hardware specifics via the file system.
     52
    5153= MiniIMFS File System =
    5254
     55''Add details''
    5356
    54 ''Add details''
    5557= RFS File System =
    5658
    5759
    5860The RTEMS File System or RFS is a block based fully standard file system that support directories, files, nodes, links and symbolic links. It is fully integrated into RTEMS libblock and libc file system support. The file system can scale from 1.5M flash disks using the flash disk driver to 120G ATA hard disks. The [wiki:TBR/UserManual/RTEMS_File_System RTEMS File System] provides details about the file system.
     61
    5962= Journalling Flash File System, Version 2 =
    6063
    6164
    6265The [http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__JFFS2.html JFFS2] port to RTEMS is based on files from Linux 3.11 and eCos.
     66
    6367= TFTP File System =
    6468
     
    6872The 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.
    6973
    70 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.
     74The 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 {{{/TFTP/10.10.10.1/readme.txt}}} would attempt to read using the TFTP protocol the file {{{readme.txt}}} from the host {{{10.10.10.1}}}. The file name used in the TFTP read request would have the leading {{{/}}} removed.
     75
    7176= FTP File System =
    7277
    7378
    7479You can sometimes read and write files.  Seek and directory listing are not supported.  Lets assume that you mounted the FTPFS to ''/FTP'', then you can access files via ''/FTP/password:user@host/dir/file'', ''/FTP/user@host/dir/file'' (password = user), or ''/FTP/host/dir/file'' (user and password = "anonymous").
     80
    7581= NFS File System =
    7682
    7783
    78 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 (update: with the RTEMS-4.9 release NFS became part of the <tt>cpukit</tt>).
     84RTEMS 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. '''Note''': prior to RTEMS 4.9 the NFS code was outside the {{{cpukit}}}. Currently, NFS became part of the {{{cpukit}}}.
     85
    7986= MSDOS File System =
    8087
    8188
    8289RTEMS 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 access various types of disk media. The file system interfaces to the cache. The cache provides a performance increase to applications using the MSDOS file system. Many FAT operations require more than one pass over a FAT directory or the FAT table and holding this data in memory increases performance. See [wiki:TBR/UserManual/Using_the_RTEMS_DOS_File_System Using the RTEMS DOS File System] to see how to configure and use this file system in RTEMS. The MSDOS file is tested against FreeDOS and Windows.
     90
    8391= Block Devices =
    8492
     
    102110
    103111Block devices are normally accessed from the block device cache and not directly. The Block Device drivers are specific to the type of hardware used to access the disk media.
     112
    104113= ATA Disk Drives =
    105114
     
    108117
    109118The ATA driver is a task that interfaces to a BSP supplied driver. The BSP initializes a table with the BSP driver functions. Initialization and mounting of a partition on an ATA disk is a 2 stage process. The Master Boot Record (MRB) is read from the disk and valid MSDOS partitions added as devices. The mounting of a partition requires a partition device path and a mount point.
     119
    110120= RAM Disk =
    111121
    112122
    113123The RAM disk allows a fixed sized disk to exist in RAM. You can provide the address of the RAM or let the driver allocate the RAM from the heap. If you create a disk from the heap you will need to format it. Providing the RAM address allows you to use static RAM that could survive a reset and may or may not need to be formatted during initialisation. If the RAM is battery backed up you may consider the Non-volatile or NVDISK driver. The RAM disk does not provide any checking on the blocks in RAM. It is the fastest block device driver.
     124
    114125= Non-Volatile Disk =
    115126
    116127
    117128The Non-volatile or NVDISK is similar to the RAM disk how-ever each block has a checksum. It provides a one to one mapping of blocks to the memory like the RAM disk but it also adds a CRC checksum on each block. The NVDISK driver is suitable for battery backed up static RAM or EEPROM type devices that are byte re-programmable.
     129
    118130= Flash Disk =
    119131
     
    122134
    123135The flash driver does manage the moving of blocks to allow the the recovery of flash segments (sectors). The compaction operation can cause flash updates to vary in length.
     136
    124137= SPI SD Card =
    125138
    126139
    127140The SPI SD Card driver is locate in libchip. It uses libi2c and despite this libraries name supports I2C and SPI serial bus interfaces.
     141
    128142= Block Device Cache =
    129143
     
    144158The cache can be synchronized at the request of a user giving an application full control over the data written to the disk media. If you do not synchronize the data with the disk media before your applications terminates data could be lost or the file system could become corrupted. To synchronize the cache for a specific disk use the following code:
    145159
     160{{{
    146161  int fd = open (driver, O_WRONLY, 0);
    147162  if (fd < 0) {
     
    157172  close (fd);
    158173  return 0;
     174}}}
     175
    159176= Device Only File System =
    160177
    161178
    162179The device-only filesystem is a light-weight filesystem only for device. It uses kernel workspace for storage. The memory consumption is a constant and can be changed during user application configuration time. The device-only filesystem is designed only for devices nodes.
     180
    163181= ATA Block Driver =
    164182
     
    166184RTEMS provides an ATA block driver the BSP provides an IDE layer for. This is a PIO mode driver so be careful your hardware is working. As Thomas stated in IRC:
    167185
    168 <blockquote>"With IDE nothing is normal. It is a really weird interface and too many people in too many committees with too many interests have tinkered around with that standard"</blockquote>
     186   "''With IDE nothing is normal. It is a really weird interface and too many people in too many committees with too many interests have tinkered around with that standard"''