EDIT: By obsolete I don't mean bad/unnecessary (I agree with /proc being a mess). Modularity is a good thing and I love it. I mean is: information of the system, held (in /sys) that is findable somewhere else.

I couldn't really find much information about /sys and /proc. Besides both of there contents not being part of the Filesystem Hierarchy Standard (because the way they, look like/are build up is kernel version depended)

/sys doesn't even have it's own man page. /proc has it's own man page, and oh boy it has pretty much explanation and still I have some folders and files (for example /acpi and consoles) which are not mentioned in it. /sys is pretty new right? And before it existed all of the info that /sys gives was part of /proc right?


Is this still the case? Can all the info form /sys be found on /proc in one or another form? That would make a documentation for /sys obsolete because it's just an expansion with user friendly design, right? Or is there any system info in /sys that isn't in some other form present in /proc?

If this is the case where is the place that explains /sys to linux amateurs?

  • In general /proc is for higher level kernel/process stuff whereas /sys is for hardware behavior. The hardware entries underneath /proc are usually older entries that pre-date /sys – Bratchley Oct 23 '16 at 23:11
  • So the only difference between the hardware info provided by both of them is the sorting and displaying? – Junaga Oct 23 '16 at 23:13
  • The difference is that the /proc hardware data/files are older. – Bratchley Oct 24 '16 at 0:16

/sys is not obsolete, on the opposite, /sys is newer that /proc and will grow in the future.

/proc (and procfs) predates Linux by several years. It was designed to allow access to running processes structures, and nothing else, and especially aimed for debuggers and similar tools. It remains restricted to this goal in current SVR4 based OSes like Solaris. On the other hand, Linux procfs implementors thought it was a good idea to use procfs to also access kernel structures unrelated to processes, thus the mixing of numerical directories directing to processes information and text files and directories given access to kernel statistics, tables and other data. This approach was ported to AIX and is partially emulated on BSDs to ease porting Linux software.

When it became obvious this approach was leading to a mess, /sys was created with a better design and some of /proc entries moved to it. Unfortunately, a lot of tools have /proc/something hardcoded so the most commonly used directory entries under /proc are here to stay.

About how to know what kind of information contains a given file under a given path under either /proc or /sys, documentation, if any, is as you noticed not easy to find. Hopefully, the kernel is open source so the last resort is to look at its code.

See also: What is the difference between procfs and sysfs? and What is in /dev, /proc and /sys?

  • >moved to it >here to stay. Sorry I know nothing about this, but: kernel information dosen't have to be in either one or the other, or not? both are virtual filesystems made by it, it can put the same info about for example(what filesystems are available for mounting, what bridges lead to other buses form the dram controller) in /proc and /sys. since I found on both of them, some info about what devices are present in the system. I asked myself Is there any info in /sys that isn't also findable in /proc ? – Junaga Oct 23 '16 at 23:35
  • Yes, of course there can be redundant paths to the same information. I just checked on a laptop and /sys has 46923 files while /proc has 1501 ones, excluding of course/proc/<pid> so yes, there must be a lot of information available under /sys that is not under /proc. – jlliagre Oct 23 '16 at 23:43
  • after digging around in /sys a lot I know that most of them if not 4/5th or so are just links that go a few dirs back – Junaga Oct 23 '16 at 23:46
  • Removing the symlinks reduce the number from 46923 to 44322 on my laptop. But this is not a fair comparison as many /sys entries only give a single statistic/value, which is simpler to handle by programs compared to the /proc usual name/value tables. – jlliagre Oct 23 '16 at 23:53
  • wtf, so many still? well mb. thanks for answering ^^ – Junaga Oct 23 '16 at 23:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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