ae1d0c04ae
This patch introduces the file-system-session interface, provides an implementation of this interface in the form of an in-memory file system, and enables the libc to use the new file-system facility. The new interface resides in 'os/include/file_system_session/'. It uses synchronous RPC calls for functions referring to directory and meta-data handling. For transferring payload from/to files, the packet-stream interface is used. I envision that the asynchronous design of the packet-stream interface fits well will the block-session interface. Compared to Unix-like file-system APIs, Genode's file-system session interface is much simpler. In particular, it does not support per-file permissions. On Genode, we facilitate binding policy (such as write-permission) is sessions rather than individual file objects. As a reference implementation of the new interface, there is the new 'ram_fs' service at 'os/src/server/ram_fs'. It stores sparse files in memory. At the startup, 'ram_fs' is able to populate the file-system content with directories and ROM modules as specified in its configuration. To enable libc-using programs to access the new file-system interface, there is the new libc plugin at 'libports/src/lib/libc-fs'. Using this plugin, files stored on a native Genode file system can be accessed using the traditional POSIX file API. To see how the three parts described above fit together, the test case at 'libports/run/libc_fs' can be taken as reference. It reuses the original 'libc_ffat' test to exercise several file operations on a RAM file-system using the libc API. :Known limitations: The current state should be regarded as work in progress. In particular the error handling is not complete yet. Not all of the session functions return the proper exceptions in the event of an error. I plan to successively refine the interface while advancing the file-system implementations. Also the support for truncating files and symlink handling are not yet implemented. Furthermore, there is much room for optimization, in particular for the handling of directory entries. Currently, we communicate only one dir entry at a time, which is bad when traversing large trees. However, I decided to focus on functionality first and defer optimizations (such as batching dir entries) to a later stage. The current implementation does not handle file modification times at all, which may be a severe limitation for tools that depend on this information such as GNU make. Support for time will be added after we have revisited Genode's timer-session interface (issue #1). Fixes #54 Fixes #171 |
||
|---|---|---|
| .. | ||
| chunk.h | ||
| directory.h | ||
| file.h | ||
| main.cc | ||
| node_handle_registry.h | ||
| node.h | ||
| README | ||
| symlink.h | ||
| target.mk | ||
| util.h | ||
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"> ! <!-- just a place holder --> ! <rom name="timer" /> ! </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. 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.