In computer science, a synthetic file system or a pseudo file system is 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-storage file system. These non-file objects may be accessed with the same system calls or utility programs as regular files and directories. The common term for both regular files and the non-file objects is node.
The benefit of synthetic file systems is that well-known file system semantics can be reused for a universal and easily implementable approach to interprocess communication. Clients can use such a file system to perform simple file operations on its nodes and do not have to implement complex message encoding and passing methods and other aspects of protocol engineering. For most operations, common file utilities can be used, so even scripting is quite easy.
This is commonly known as everything is a file and is generally regarded to have originated from Unix.
In the Unix-world, there is commonly a special filesystem mounted at /proc. This filesystem is implemented within the kernel and publishes information about processes. For each process, there is a directory (named by the process 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 in Plan 9 from Bell Labs.[2]
Linux /sys filesystem
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
ObexFS is a FUSE-based filesystem that provides access to OBEX objects via a filesystem. Applications can work on remote objects via the OBEX protocol as if they were simply (local) files.
Plan 9 file servers
On the Plan 9 from Bell Labs operating system family, the concept of 9P synthetic filesystem is used as a generic IPC method. 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
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 on 9P, 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
The major argument for using synthetic filesystems might be the flexibility and easy access to service-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, complex remote procedure calls with many parameters tend to be hard to map to filesystem schemes,[citation needed] and may require application redesign.
References
^"proc page from Section 4 of the unix 8th manual". Man.cat-v.org. Retrieved 2015-08-28.
^"Proc page from Section 3 of the plan 9 manual". Man.cat-v.org. Retrieved 2015-08-28.
BROWN, Geoffrey: On-Chip Filesystems to support Complex Embedded Systems[dead link]
PISUPATI, Bhani N.: A virtual filesystem framework to support embedded software development
Minnich, Ron:
January 07, 2023
synthetic, file, system, this, article, relies, excessively, references, primary, sources, please, improve, this, article, adding, secondary, tertiary, sources, find, sources, news, newspapers, books, scholar, jstor, august, 2015, learn, when, remove, this, te. This article relies excessively on references to primary sources Please improve this article by adding secondary or tertiary sources Find sources Synthetic file system news newspapers books scholar JSTOR August 2015 Learn how and when to remove this template message In computer science a synthetic file system or a pseudo file system is 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 storage file system These non file objects may be accessed with the same system calls or utility programs as regular files and directories The common term for both regular files and the non file objects is node The benefit of synthetic file systems is that well known file system semantics can be reused for a universal and easily implementable approach to interprocess communication Clients can use such a file system to perform simple file operations on its nodes and do not have to implement complex message encoding and passing methods and other aspects of protocol engineering For most operations common file utilities can be used so even scripting is quite easy This is commonly known as everything is a file and is generally regarded to have originated from Unix Contents 1 Examples 1 1 proc filesystem 1 2 Linux sys filesystem 1 3 ObexFS 1 4 Plan 9 file servers 1 5 Embedded systems 2 Pros and cons 3 References 4 External linksExamples Edit proc filesystem Edit In the Unix world there is commonly a special filesystem mounted at proc This filesystem is implemented within the kernel and publishes information about processes For each process there is a directory named by the process 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 in Plan 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 a FUSE based filesystem that provides access to OBEX objects 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 the Plan 9 from Bell Labs operating system family the concept of 9P synthetic filesystem is used as a generic IPC method 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 on 9P 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 EditThe major argument for using synthetic filesystems might be the flexibility and easy access to service 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 complex remote procedure calls with 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 Retrieved 2015 08 28 Proc page from Section 3 of the plan 9 manual Man cat v org Retrieved 2015 08 28 9P Implementations 9p cat v org Retrieved 2015 08 28 External links EditThe 9P synthetic file system protocol BROWN Geoffrey On Chip Filesystems to support Complex Embedded Systems dead link PISUPATI Bhani N A virtual filesystem framework to support embedded software development Minnich Ron Why Plan9 is not dead And What we can learn from it Retrieved from https en wikipedia org w index php title Synthetic file system amp oldid 1091200575, wikipedia, wiki, book, books, library,
