| Version 6 (modified by , 15 years ago) ( diff ) |
|---|
Implementation and design of the file system layer
Unlike in monolithic designs, the file system functionality is spread across several layers in HelenOS:
Standard library support
The standard library translates more or less POSIX file system requests made by the user application to the VFS server frontend protocol and passes them to VFS. The library emulates some calls such as opendir(), readdir(), rewinddir() and closedir() using other calls. In this case these will be open(), read(), lseek() and close().
The VFS server accepts only absolute file paths and so the standard library takes care of providing the getcwd() and chdir() interfaces. It also translates all relative paths to absolute. Passing absolute paths may not be always optimal, but it simplifies the design of the VFS server and the libfs algorithms. In addition, thanks to this feature, the dot-dot file path components can be processed lexically, which leads to further simplifications.
The standard library forwards all other requests, which it is unable to handle itslef, to the VFS server and does not contribute to the file system functionality by any other means. Each file system request forwarded to VFS is composed of one or more IPC phone calls.
VFS server
The VFS server is the focal point and also the most complex element of the file system support in the HelenOS operating system. It exists as a standalone user task. We talk about the VFS frontend and VFS backend.
The frontend is responsible for accepting requests from the client tasks. Their arguments are either absolute file paths, file handles of already opened files, and in some special cases also VFS triplets (see below).
Path arguments
If the argument is a file path, VFS uses the vfs_lookup_internal() function to translate the path into the so called VFS triplet. A VFS triplet is an ordered triplet containing a global handle of the file system instance, a global device handle and a file index. Thus a VFS triplet uniquely identifies a file on some file system instance. An example VFS triplet could look like this:
(2, 1, 10)
In the above example, the VFS triplet describes a file on a file system which was assigned number 2 by the VFS service, located on a device, which was assigned number 1 by the DEVMAP service, and which has a file-system specific index number 10. The last number is also known as i-node number in other operating systems.
VFS keeps information about each referenced file in an abstraction called VFS node, for which there is the vfs_node_t type. Thus, a VFS node represents some file which is referenced by VFS.
