| 1 | = Implementation and design of the file system layer = |
| 2 | |
| 3 | Unlike in monolitic designs, the file system functionality is spread across |
| 4 | several layers in HelenOS: |
| 5 | |
| 6 | * [#FSDesignLibc standard library support], |
| 7 | * [#FSDesignVFS VFS server], |
| 8 | * [#FSDesignFS set of individual file system servers], and |
| 9 | * [#FSDesignLibFS libfs library]. |
| 10 | |
| 11 | == Standard library support == #FSDesignLibc |
| 12 | |
| 13 | The standard library translates more or less POSIX file system requests made by |
| 14 | the user application to the VFS server frontend protocol and passes them to |
| 15 | ''VFS''. The library emulates some calls such as ''opendir()'', ''readdir()'', |
| 16 | ''rewinddir()'' and ''closedir()'' using other calls. In this case these will |
| 17 | be ''open()'', ''read()'', ''lseek()'' and ''close()''. |
| 18 | |
| 19 | The VFS server accepts only absolute file paths and so the standard library |
| 20 | takes care of providing the ''getcwd()'' and ''chdir()'' interfaces. It also |
| 21 | translates all relative paths to absolute. Passing absolute paths may not be |
| 22 | always optimal, but it simplifies the design of the VFS server and the libfs |
| 23 | algorithms. In addition, thanks to this feature, the ''..'' file path |
| 24 | components can be processed lexically, which leads to further simplifications. |
| 25 | |
| 26 | The standard library forwards all other requests, which it is unable to handle |
| 27 | itslef, to the VFS server and does not contribute to the file system |
| 28 | functionality by any other means. Each file system request forwarded to VFS |
| 29 | is composed of one or more IPC phone calls. |