genode/os/src/server/ram_fs
Norman Feske fae63f4fa9 Merge base libraries into a single library
This patch simplifies the way of how Genode's base libraries are
organized. Originally, the base API was implemented in the form of many
small libraries such as 'thread', 'env', 'server', etc. Most of them
used to consist of only a small number of files. Because those libraries
are incorporated in any build, the checking of their inter-dependencies
made the build process more verbose than desired. Also, the number of
libraries and their roles (core only, non-core only, shared by both core
and non-core) were not easy to capture.

Hereby, the base libraries have been reduced to the following few
libraries:

- startup.mk contains the startup code for normal Genode processes.
  On some platform, core is able to use the library as well.
- base-common.mk contains the parts of the base library that are
  identical by core and non-core processes.
- base.mk contains the complete base API implementation for non-core
  processes

Consequently, the 'LIBS' declaration in 'target.mk' files becomes
simpler as well. In the most simple case, only the 'base' library must
be mentioned.

Fixes #18
2013-02-19 14:45:55 +01:00
..
README Allow defining ram_fs file content from config 2012-05-18 17:07:30 +02:00
chunk.h Update copyright headers to 2013 2013-01-10 21:44:47 +01:00
directory.h Introduce notifications to file-system interface 2013-01-15 10:18:07 +01:00
file.h Introduce notifications to file-system interface 2013-01-15 10:18:07 +01:00
main.cc Introduce notifications to file-system interface 2013-01-15 10:18:07 +01:00
node.h Introduce notifications to file-system interface 2013-01-15 10:18:07 +01:00
node_handle_registry.h Introduce notifications to file-system interface 2013-01-15 10:18:07 +01:00
symlink.h Add support for symbolic links 2012-10-08 15:05:02 +02:00
target.mk Merge base libraries into a single library 2013-02-19 14:45:55 +01:00
util.h File-system interface, ram_fs, libc-fs 2012-05-17 20:33:53 +02:00

README

This directory contains an in-memory file-system implementation.

Configuration
~~~~~~~~~~~~~

Access to the file system can be tailored for each session depending on the
session's label. By default, no permissions are granted to any session.
To selectively permit access to (a part of) the file system, at least one
ram_fs policy must be defined.

The following configuration illustates the way of how to express policy.

! <config>
!   <!-- preload RAM file system with some ROM images -->
!   <content>
!     <dir name="tmp">
!       <rom name="init" as="blubb" />
!     </dir>
!     <dir name="home">
!       <dir name="user">
!         <inline name=".vimrc">
!           set hidden
!         </inline>
!       </dir>
!     </dir>
!   </content>
!   <!-- constrain sessions according to their labels -->
!   <policy label="noux -> root" root="/" />
!   <policy label="noux -> home" root="/home/user" writeable="yes" />
!   <policy label="noux -> tmp"  root="/tmp"       writeable="yes" />
! </config>

The '<content>' sub node of the '<config>' node provides a way to pre-populate
the file system with directories and files. Note that '<dir>' nodes can be
arbitrarily nested. Files can be loaded from the ROM service. By adding the
optional 'at' attribute to a rom node, the file name can be defined
independently from the ROM module name. In addition to creating files from
ROM modules, files can be created from data specified directly as part of the
configuration using '<inline>' nodes. The content of such nodes is used as
file content as is.

Session-specific access-control policy is expressed via one or more '<policy>'
nodes. At session-creation time, each policy node is matched against the label
of the new session. If the label of a policy node matches, the defined policy
is applied. If multiple policies match, the one with the longest 'label'
attribute (the most specific one) is selected.

A policy node may contain the following attributes. The mandatory 'root'
attribute defines the viewport of the session onto the file system. The
optional 'writeable' attribute grants the permission to modify the file system.


Example
~~~~~~~

To illustrate the use of ram_fs, refer to the 'libports/run/libc_fs.run'
script.