/dev/shmem RAM "filesystem"

Neutrino provides a simple RAM-based filesystem that allows read/write files to be placed under /dev/shmem.

Note that /dev/shmem isn't actually a filesystem. It's a window onto the shared memory names that happens to have some filesystem-like characteristics.

The files in the /dev/shmem directory are advertised as name-special files (S_IFNAM), which fools many utilities — such as more — that expect regular files (S_IFREG). For this reason, many utilities might not work for the RAM filesystem.

If you want to use gzip to compress or expand files in /dev/shmem, you need to specify the -f option.

This filesystem is mainly used by the shared memory system of procnto . In special situations (e.g. when no filesystem is available), you can use the RAM filesystem to store file data. There's nothing to stop a file from consuming all free RAM; if this happens, other processes might have problems.

You'll use the RAM filesystem mostly in tiny embedded systems where you need a small, fast, temporary-storage filesystem, but you don't need persistent storage across reboots.

The filesystem comes for free with procnto and doesn't require any setup or device driver. You can simply create files under /dev/shmem and grow them to any size (depending on RAM resources).

Although the RAM filesystem itself doesn't support hard or soft links or directories, you can create a link to it by using process-manager links. For example, you could create a link to a RAM-based /tmp directory:

ln -sP /dev/shmem /tmp

This tells procnto to create a process-manager link to /dev/shmem known as /tmp. Most application programs can then open files under /tmp as if it were a normal filesystem.

In order to minimize the size of the RAM filesystem code inside the process manager, this filesystem specifically doesn't include big filesystem features such as:
  • file locking
  • directories
  • . and .. entries for the current and parent directories
  • hard or soft links
  • protection from overwriting running executables. A real filesystem gives an error of EBUSY if you try this; in /dev/shmem, the running executable will likely crash. This is because being able to write to a shared memory object while somebody else has it open is the whole point of shared memory.