RTEMS 4.8.0 On-Line Library

RTEMS Filesystem Design Guide

6.1: IMFS Per Node Data Structure

Each regular file, device, hard link, and directory is represented by a data structure called a jnode. The jnode is formally represented by the structure:

struct IMFS_jnode_tt {
  Chain_Node          Node;             /* for chaining them together */
  IMFS_jnode_t       *Parent;           /* Parent node */
  char                name[NAME_MAX+1]; /* "basename" */
  mode_t              st_mode;          /* File mode */
  nlink_t             st_nlink;         /* Link count */
  ino_t               st_ino;           /* inode */

  uid_t               st_uid;           /* User ID of owner */
  gid_t               st_gid;           /* Group ID of owner */
  time_t              st_atime;         /* Time of last access */
  time_t              st_mtime;         /* Time of last modification */
  time_t              st_ctime;         /* Time of last status change */
  IMFS_jnode_types_t  type;             /* Type of this entry */
  IMFS_typs_union     info;
};

The key elements of this structure are listed below together with a brief explanation of their role in the filesystem.

Node

exists to allow the entire jnode structure to be included in a chain.

Parent

is a pointer to another jnode structure that is the logical parent of the node in which it appears. This field may be NULL if the file associated with this node is deleted but there are open file descriptors on this file or there are still hard links to this node.

name

is the name of this node within the filesystem hierarchical tree. Example: If the fully qualified pathname to the jnode was /a/b/c, the jnode name field would contain the null terminated string "c".

st_mode

is the standard Unix access permissions for the file or directory.

st_nlink

is the number of hard links to this file. When a jnode is first created its link count is set to 1. A jnode and its associated resources cannot be deleted unless its link count is less than 1.

st_ino

is a unique node identification number

st_uid

is the user ID of the file's owner

st_gid

is the group ID of the file's owner

st_atime

is the time of the last access to this file

st_mtime

is the time of the last modification of this file

st_ctime

is the time of the last status change to the file

type

is the indication of node type must be one of the following states:

• IMFS_DIRECTORY
• IMFS_MEMORY_FILE
• IMFS_HARD_LINK
• IMFS_SYM_LINK
• IMFS_DEVICE

info

is this contains a structure that is unique to file type (See IMFS_typs_union in imfs.h).

• IMFS_DIRECTORY

  An IMFS directory contains a dynamic chain structure that records all files and directories that are subordinate to the directory node.

• IMFS_MEMORY_FILE

  Under the in memory filesystem regular files hold data. Data is dynamically allocated to the file in 128 byte chunks of memory. The individual chunks of memory are tracked by arrays of pointers that record the address of the allocated chunk of memory. Single, double, and triple indirection pointers are used to record the locations of all segments of the file. The memory organization of an IMFS file are discussed elsewhere in this manual.

• IMFS_HARD_LINK

  The IMFS filesystem supports the concept of hard links to other nodes in the IMFS filesystem. These hard links are actual pointers to other nodes in the same filesystem. This type of link cannot cross-filesystem boundaries.

• IMFS_SYM_LINK

  The IMFS filesystem supports the concept of symbolic links to other nodes in any filesystem. A symbolic link consists of a pointer to a character string that represents the pathname to the target node. This type of link can cross-filesystem boundaries. Just as with most versions of UNIX supporting symbolic links, a symbolic link can point to a non-existent file.

• IMFS_DEVICE

  All RTEMS devices now appear as files under the in memory filesystem. On system initialization, all devices are registered as nodes under the file system.

RTEMS Filesystem Design Guide

Copyright © 1988-2007OAR Corporation