What is the difference between procfs and sysfs? Why are they made as file systems? As I understand it, proc is just something to store the immediate info regarding the processes running in the system.
What is the difference between procfs and sysfs?
proc is the old one, it is more or less without rules and structure. And at some point it was decided that
proc was a little too chaotic and a new way was needed.
sysfs was created, and the new stuff that was added was put into
sysfs like device information.
So in some sense they do the same, but
sysfs is a little bit more structured.
Why are they made as file systems?
UNIX philosophy tells us that everything is a "file", therefore it was created so it behaves as files.
As I understand it, proc is just something to store the immediate info regarding the processes running in the system.
Those parts has always been there and they will probably never move into
But there is more old stuff that you can find in
proc, that has not been moved.
In the beginning (way back in Unix), the way that programs found out about the running processes on the system was via directly reading process structures from the kernel memory (opening /dev/mem, and interpreting the raw data directly). This is how the very first 'ps' commands worked. Over time, some information was made available via system calls.
However, it is bad form to expose system data directly to user-space via /dev/mem, and obnoxious to be constantly creating new system calls every time you wanted to export some new piece of process data, and so a newer method was created to access structured data for user-space applications to find out about process attributes. This was the /proc filesystem. With /proc, the interfaces and structures (directories and files) could be kept the same, even as the underlying data structures in the kernel changed. This was much less fragile than the earlier system, and it scaled better.
The /proc filesystem was originally designed to publish process information and a few key system attributes, required by 'ps', 'top', 'free' and a few other system utilities. However, because it was easy to use (both from the kernel side and the user-space side), it became a dumping ground for a whole range of system information. Also, it started to gain read/write files, to be used to adjust settings and control the operation of the kernel or its various subsystems. However, the methodology of implementing control interfaces was ad-hoc, and /proc soon grew into a tangled mess.
The sysfs (or /sys filesystem) was designed to add structure to this mess and provide a uniform way to expose system information and control points (settable system and driver attributes) to user-space from the kernel. Now, the driver framework in the kernel automatically creates directories under /sys when drivers are registered, based on the driver type and the values in their data structures. This means that drivers of a particular type will all have the same elements exposed via sysfs.
Many of the legacy system information and control points are still accessible in /proc, but all new busses and drivers should expose their info and control points via sysfs.
procfs allows arbitrary
file_operations, sysfs is more restricted
procfs entries receive a
file_operationsstruct, which contains function pointers that determine what happens to every file-based system call, e.g.
mmap, etc., and you can take arbitrary actions from those.
sysfs is more restricted in the following senses:
- you implement only two methods
store, which Linux uses to implement
lseekfor you. See also: How to attach file operations to sysfs attribute in platform driver? | Stack Overflow
- tightly coupled with
- you implement only two methods
sysfs is the Virtual Filesystem created during the 2.6 Kernel release cycle to show device information as procfs did not do this type of information that well.
Memory etc has not been ported to sysfs as it was never intended to show that type of information so it is unlikely it will be ported at all.