Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question

3 Answers 3

up vote 17 down vote accepted

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 to chaotic and a new way was needed.

Then 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 sysfs.

But there is more old stuff that you can find in proc, that has not been moved.

share|improve this answer
1  
Thanks for the answer.. But why are cpuinfo and meminfo like things still maintained in procfs? Why cant they be moved to sysfs? –  Sen Dec 16 '10 at 10:20
2  
I guess they put new stuff in sysfs, and just leave the old as it is to keep some level of backwards compability. There is a lot of stuff that depends on those things in proc... –  Johan Dec 16 '10 at 14:11

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.

share|improve this answer
    
One reason that it's "bad form" to use /dev/mem and /dev/kmem is that they require root access, so the applications that use them have to be setuid. –  Barmar Aug 8 at 18:13

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.

share|improve this answer
    
Memory etc has not been ported to sysfs What do you mean by porting? And why was it not intended to show that type of information? Could you please explain that to me. –  Sen Dec 16 '10 at 11:56
    
By ported i meant moved which was an answer to your question of if Memory etc will be moved to sysfs. And it was only ever intended to show device information as that was the thing that procfs did not do well, procfs is still excellent for other types of information. –  kemra102 Dec 16 '10 at 13:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.