Book:Storage:VfsBuiltIns

Not logged in

Built-in File Systems

A dozen file systems are provided by vfs.lib.so itself (by opposed to being provided by shared objects loaded at run time) : an inline FS, tar-archive FS, Ram FS and so on.

By adding XML tags with specific names, you instantiate new instances of those file systems and insert them into your VFS directory tree.

"Clashing" names handling : multiple file systems added inside the same parent directory might "collide". Such conflicts are handled union-fs style : the file from the first (top-most) file-system will get exposed in priority, shadowing the one that comes later down.

1. Inline FS

This file system allows you to populate your VFS instance with a directory hierarchy and simple text files, by adding the corresponding XML tags inside your <vfs>...</vfs> config file.

See Genodians - Genodes VFS #1: The basics for more, and for info on the <import> feature (provided by an /external/ plugin), which allows to populate an arborescence -- for example populate a Ram FS node, which would otherwise start its life blank.

a. Directories

Example:
<dir name="etc">
  <dir name="ssh-settings">
  </dir>
</dir>

The above will create "/etc/ssh-settings/".

b. hardcoded Text Files

Example:
<inline name="playlist.txt">
  beos.mp3
  catastrophe-records.mp3
</inline>

2. Log FS

This inserts into your VFS instance a node named "log" which provides/bridges access to Genode's LOG service : any call to POSIX write() targetting this node will get translated into LOG logging lines. Typically used in cunjunction with a <dir> tag, so as to locate the node inside a "dev" directory, the de-facto standard used in Genode's libc.

Example:

<dir name="dev">
  <log/>
</dir>

3. Ram FS

This inserts a volatile (temporary) read-write file system within your VFS instance.

Example:

<ram/>

This FS does not have to be 'flat', one may create any number of directories and sub-directories and files. The contents is lost as soon as the host program exits.

4. ROM FS

The ROM file system gives read-only access to "boot modules", i.e. files embedded in the ISO's image.elf.gz (those loaded into computer memory at boot up and listed early in the serial output).

This describes how to setup simple files at the top level of the boot image: they're thus located side by side with init, ld.lib.so ..etc, yet can be read normally by the C lib's fopen() ..etc just as if they were in the "/" top level hierarchy of a *nix system.

1. create a copy of your file in the bin folder (e.g. genode/build/x86_64/bin).

2. modify your run file's "append boot_modules" section so that it will include that file in the ISO image.

3. modify your run file, specifically the 'launcher' of the concerned component, and add a config/vfs section. For instance to allow component "CommandCenter.." to access "background.jpeg" you would use:

	<start name="CommandCenter" caps="250">
		<resource name="RAM" quantum="15M"/>
		<config>
			<vfs>
				<rom name="background.jpeg"/>
			</vfs>
		</config>
	</start>

4. you're all set -- your C++ code may call e.g.

FILE * file = fopen( "background.jpeg", "rb" );