1Filesystem drivers 2==================================== 3 4Filesystem drivers are in src/add-ons/kernel/file_system 5 6A filesystem usually relies on an underlying block device, but that's not 7required. For example, NFS is a network filesystem, so it doesn't need one. 8 9Implementation notes 10-------------------- 11 12Each filesystem driver must define a few structures which act as the 13interface between the VFS and the filesystem implementation. These 14structures contain function pointers, some of which are optional, 15which should point to functions defined by the implementer that 16perform the appropriate filesystem peration as defined by the 17documentation. 18 19See docs/user/drivers/fs_interface.dox for more detailed documentation 20of this interface. 21 22It's important to note that while there may be some similarities in 23the interface with that of other operations systems, one should not 24make any assumptions about the desired behavior based soley on the 25function prototypes defined in fs_interface.h. 26 27The following is a list of notes calling out some potential mistakes. 28 29# fs_vnode_ops.read_symlink 30 31Defining this function means that the filesystem driver supports 32symbolic links, and the function that f_vnode_ops.read_symlink points 33to should read the contents of a symlink from the specified node. 34 35This may seem similar to the posix function readlink(), but it is 36slightly different. Unlike readlink(), which returns the number of 37bytes copied into the output buffer, fs_vnode_ops.read_symlink is 38expected to always return the length of the symlink contents, even if 39the provided buffer is not large enough to contain the entire symlink 40contents. 41 42Development tools 43----------------- 44 45# fs_shell 46 47It is not convenient to test a filesystem by reloading its driver into a 48running Haiku system (kernel debugging is often not as easy as userland). 49Moreover, the filesystem interacts with other components of the system 50(file cache, block cache, but also any application reading or writing files). 51 52For the early development steps, it is much easier to run the filesystem code 53in a more controlled environment. This can be achieved through the use of 54a "filesystem shell": a simple application that runs the filesystem code, and 55allows performing specific operations through a command line interface. 56 57Example of fs_shell implementations are available under src/tests/add-ons/kernel/file_systems/ 58for the bfs and btrfs filesystems. 59 60For example, to build the fs_shell for btrfs, use 61 62 jam -q "<build>btrfs_shell" 63 64To run it, use 65 66 jam run objects/haiku_host/x86_gcc2/release/tests/add-ons/kernel/file_systems/btrfs/btrfs_shell/btrfs_shell [arguments] 67 68You need to pass at least a file or device containing a filesystem image as an 69argument. You need some tool to create one. It is possible to work using an 70actual disk volume (but be careful, it's risky to use one with useful data in it), 71a file, or a RAM disk, depending on what you are doing. 72 73# userlandfs 74 75As a second step, it's possible to use the filesystem as part of a runing 76system, while still running it in userland. This allows use of Debugger, 77memory protection, and in general any kind of userland debugging or tracing 78tool. When the filesystem crashes, it does not bring down the whole system. 79 80Userlandfs can run the filesystem code using the same interface as the kernel, 81therefore, once everything is working with userlandfs, running the filesystem 82as kernel code is usually quite easy (and provides a performance boost) 83 84# Torture and performance tests 85 86Once the basic operations are working fine, it is a good idea to perform more 87agressive testing. Examples of scripts doing this are available in 88src/tests/add-ons/kernel/file_systems/ for the fat and ext2 filesystems. 89 90.. toctree:: 91 92 /file_systems/ufs2 93 /file_systems/befs/resources 94