Synthetic file system
 |
Incomputer science,asynthetic file systemor apseudo file systemis a hierarchical interface to non-file objects that appear as if they were regular files in the tree of a disk-based or long-term-storagefile system.These non-file objects may be accessed with the samesystem callsorutility programsas regular files anddirectories.The common term for both regular files and the non-file objects isnode.
The benefit of synthetic file systems is that well-known file system semantics can be reused for a universal and easily implementable approach tointerprocess communication.Clients can use such a file system to perform simple file operations on its nodes and do not have to implement complexmessage encoding and passingmethods and other aspects ofprotocol engineering.For most operations, common file utilities can be used, so evenscriptingis quite easy.
This is commonly known aseverything is a fileand is generally regarded to have originated fromUnix.
Examples[edit]
/proc filesystem[edit]
In the Unix-world, there is commonly a special filesystemmountedat/proc.This filesystem is implemented within thekerneland publishes information aboutprocesses.For each process, there is a directory (named by theprocess ID), containing detailed information about the process:status,open files,memory maps,mounts, etc.
/proc first appeared in Unix 8th Edition,[1]and its functionality was greatly expanded inPlan 9 from Bell Labs.[2]
Linux /sys filesystem[edit]
The /sys filesystem on Linux complements /proc, by providing a lot of (non-process related) detailed information about the in-kernel status to userspace. More traditional Unix systems locate this information in sysctl calls.
ObexFS[edit]
ObexFS is aFUSE-based filesystem that provides access toOBEXobjects via a filesystem. Applications can work on remote objects via the OBEX protocol as if they were simply (local) files.
Plan 9 file servers[edit]
On thePlan 9 from Bell Labsoperating system family, the concept of9Psynthetic filesystem is used as a genericIPCmethod. Contrary to most other operating systems, Plan 9's design is heavily distributed: while in other OS worlds, there are many (and often large) libraries and frameworks for common things, Plan 9 encapsulates them into fileservers. The most important benefit is that applications can be much simpler and that services run network and platform agnostic - they can reside on virtually any host and platform in the network, and virtually any kind of network, as long the fileserver can be mounted by the application.
Plan 9 drives this concept expansively: most operating system services, e.g. hardware access and networking stack are presented as fileservers. This way it is trivial to use these resources remotely (e.g. one host directly accessing another host's block devices or network interfaces) without the need of additional protocols.
Other implementations of the 9P file system protocol also exists for many other systems and environments.[3]
Embedded systems[edit]
Debugging embedded systems or even system-on-chip (SoC) devices is widely known to be difficult.[citation needed] Several protocols have been implemented to provide direct access to in-chip devices, but they tend to be proprietary, complex and hard to handle.
Based on9P,Plan 9's network filesystem, studies suggest using synthetic filesystems as universal access scheme to that information. The major benefit is that 9P is very simple and so quite easy to implement in hardware and can be easily used and over virtually any kind of network (from a serial link up to the internet).
Pros and cons[edit]
The major argument for using synthetic filesystems might be the flexibility and easy access toservice-oriented architectures.Once a noticeable number of applications use this scheme, the overall overhead (code, resource consumption, maintenance work) can be reduced significantly. Many general arguments for SOAs also apply here.
Arguments against synthetic filesystems include the fact that filesystem semantics may not fit all application scenarios. For example, complexremote procedure callswith many parameters tend to be hard to map to filesystem schemes,[citation needed]and may require application redesign.
References[edit]
- ^"proc page from Section 4 of the unix 8th manual".Man.cat-v.org.Retrieved2015-08-28.
- ^"Proc page from Section 3 of the plan 9 manual".Man.cat-v.org.Retrieved2015-08-28.
- ^"9P Implementations".9p.cat-v.org.Retrieved2015-08-28.