Filesystem API |
A filesystem Application_programming_interface is an application programming interface that allows developers to add support of a filesystem to an operating system without needing the second to know anything about what filesystem is it or how it works.
It is similar in functionality to driver APIs, as programs and the operating system itself know nothing about the filesystem.
Ocassionally they also provide interfaces so common filesystem maintenance functions (such as making a new filesystem, checking the metadata s integrity, defraging it and so on) became universal and transparent to the applications that handle them.
=History=
In the principle, the operating systems were capable of handling only a disk filesystem, but as systems expanded two problems arose:
With the old scheme, all filesystems and network protocols are specific to the operating system s kernel and when the user tried to access a file the whole kernel knowed how the filesystem or network protocol worked. With the two problems arised, this scheme meant that adding support for a filesystem will require a major kernel rewrite, and this wasn t acceptable, so operating systems designer think about separating the specific filesystem code from the file and network handling code of the kernels, and the filesystem APIs appeared.
=Kernel-based API=
The API is kernel-based when the kernel not only provides the interfaces for the filesystems developers but is also where the filesystem code reside.
It differs with the old schema in that the kernel itself uses its own facilities to talk with the filesystems and viceversa, as contrary to being the kernel the one that handles the filesystem layout and the filesystem the one that directly access the hardware.
Isn t the cleaner scheme but resolves the difficulties of major rewrite that has the old scheme.
With modular kernels it allows adding filesystems as any kernel module, even third party ones. With non-modular kernels however it requires the kernel to be recompiled with the new filesystem code (and in closed-source kernels, this makes third party filesystem impossible).
Unixes and Unix-like systems such as Linux use this scheme.
There is a variation of this scheme that is used in MS-DOS (DOS 4.0 onward) and compatibles for making it support CD-ROM and network filesystems, that instead of adding code to the kernel as in the old scheme or using kernel facilities as in the kernel-based scheme, it traps all calls to a file and identifies if it should be redirected to the kernel s equivalent function or if it has to be handled by the specific filesystem driver, and the filesystem driver directly access the disk contents using the classic low-level BIOS functions.
=Driver-based API=
The API is driver-based when the kernel provides facilities but the filesystem code resides totally external to the kernel (not even as a module of a modular kernel).
It is the cleaner scheme as the filesystem code is totally independent, it allows filesystems to be created for closed-source kernels and on-line filesystem addition or extraction to/from the system.
Examples of this scheme are the Windows_NT and OS/2 respective Installable_File_System.
=Mixed kernel-driver-based API=
In this API all filesystems are in the kernel, like in kernel-based APIs, but they are automatically trapped by another API, that is driver-based, by the OS.
This scheme was used in Windows_3.1 for providing a FAT filesystem driver in 32-bit protected mode, and cached, (VFAT) that bypassed the DOS FAT driver in the kernel (MSDOS.SYS) completely, and later in the Windows 9x series (Windows_95, Windows_98 and Windows_Me) for VFAT, the ISO9660 filesystem driver (along with Joliet), network shares, and third party filesystem drivers, as well as adding to the original DOS APIs the LFN API (that IFS drivers can not only intercept the already existent DOS file APIs but also add new ones from within the 32-bit protected mode executable).
However that API was almost not documented, and third parties found themselves in a make-it-by-yourself scenario even worse than with kernel-based APIs.
=Userland-based API=
The API is userland when the filesystem doesn t use kernel facilities (if they are available) but access disks using high-level operating system functions and provides functions in a library that a series of utilities uses to access the filesystem.
This is very useful for handling disk images.
The great advantage is that the filesystem can be easily portable between operating system as the high-level functions it will be using can be as common as ANSI C, but the great disadvantage is that the API is uniquely to each application that implements one.
Examples of this scheme are the [http://www.mars.org/home/rob/proj/hfs/ hfsutils] and the [http://lclevy.club.fr/adflib/ adflib].
=Interoperatibility between filesystem APIs=
As all filesystems (at least the disk ones) should need equivalent functions provided by the kernel, it is possible to easily port a filesystem code from one API to another, even if they are of different types.
For example, the ext2 driver for OS/2 is simply a wrapper from the Linux s VFS to the OS/2 s IFS and the Linux s ext2 kernel-based, and the HFS driver for OS/2 is a port of the hfsutils to the OS/2 s IFS. And there exists also a project that uses a Windows NT IFS driver for making NTFS work under Linux.
=Bibliography=
=See also=
=External links=
|
|