File systems overview---------------------Each filesystem driver must define a few structures which act as theinterface between the VFS and the filesystem implementation. Thesestructures contain function pointers, some of which are optional,which should point to functions defined by the implementer thatperform the appropriate filesystem operation as defined by thedocumentation.See docs/user/drivers/fs_interface.dox for more detailed documentationof this interface.It's important to note that while there may be some similarities inthe interface with that of other operations systems, one should notmake any assumptions about the desired behavior based soley on thefunction prototypes defined in fs_interface.h.The following is a list of notes calling out some potential mistakes.# fs_vnode_ops.read_symlinkDefining this function means that the filesystem driver supportssymbolic links, and the function that f_vnode_ops.read_symlink pointsto should read the contents of a symlink from the specified node.This may seem similar to the posix function readlink(), but it isslightly different. Unlike readlink(), which returns the number ofbytes copied into the output buffer, fs_vnode_ops.read_symlink isexpected to always return the length of the symlink contents, even ifthe provided buffer is not large enough to contain the entire symlinkcontents.Development tools-----------------fs_shell........It is not convenient to test a filesystem by reloading its driver into arunning Haiku system (kernel debugging is often not as easy as userland).Moreover, the filesystem interacts with other components of the system(file cache, block cache, but also any application reading or writing files).For the early development steps, it is much easier to run the filesystem codein a more controlled environment. This can be achieved through the use ofa "filesystem shell": a simple application that runs the filesystem code, andallows performing specific operations through a command line interface. It can beexecuted on any platform (Haiku or another supported one such as Linux).Example of fs_shell implementations are available under src/tests/add-ons/kernel/file_systems/for the bfs and btrfs filesystems.For example, to build the fs_shell for btrfs, use.. code-block:: bashjam -q "<build>btrfs_shell"To run it, use.. code-block:: bashjam run ":<build>btrfs_shell" <.img file>:ref:`XFS Page` has a concrete example which can be tweaked for other filesystems.You need to pass at least a file or device containing a filesystem image as anargument. You need some tool to create one. It is possible to work using anactual disk volume (but be careful, it's risky to use one with useful data in it),a file, or a RAM disk, depending on what you are doing.userlandfs..........As a second step, it's possible to use the filesystem as part of a runningsystem, while still running it in userland. This allows use of Debugger,memory protection, and in general any kind of userland debugging or tracingtool. When the filesystem crashes, it does not bring down the whole system.Userlandfs can run the filesystem code using the same interface as the kernel,therefore, once everything is working with userlandfs, running the filesystemas kernel code is usually quite easy (and provides a performance boost)See more here: :ref:`Userland FS Page`Torture and performance tests.............................Once the basic operations are working fine, it is a good idea to perform moreagressive testing. Examples of scripts doing this are available insrc/tests/add-ons/kernel/file_systems/ for the fat and ext2 filesystems.