0

Is the information that the Linux kernel provides to the user via sysfs a strict subset of the information that the Linux kernel provides to the user via procfs?

If not, then which information is provided via sysfs that is not provided via procfs?

Improve this question
7
  • 1
    It pretty clearly isn't; e.g. /sys/power/state has no equivalent under /proc. Don't know what the rule is for what stuff goes where. Commented May 3, 2016 at 18:02
  • @TomHunt, thanks :) "e.g. /sys/power/state has no equivalent under /proc". You're probably right. procfs is sufficiently arcane to me that I'm not currently confident drawing that sort of conclusion myself. So, it might be pretty clear to you, but not to me. And therefore maybe not so clear to other people at a similar level of understanding to me. Hence the value in posting the question here - the answers might help me and them alike :) Commented May 3, 2016 at 18:10
  • I'm going to be somewhat nasty here and point out that should you have read the documentation for proc and sysfs, the answer would be obvious. Hence, it'd be best to read the documentation. Commented May 3, 2016 at 18:16
  • @SamiLaine, thanks. I did already look at that documentation. The answer was still not obvious to me. To accurately answer the question of whether sysfs exposes a strict subset of the information exposed by procfs requires either exhaustive knowledge of sysfs & substantial knowledge of procfs (the docs aren't exhaustive), or else knowledge of at least one datum in sysfs definitely not present in procfs. Tom Hunt suggested /sys/power/state as a possible example of the latter. Another (true on my system) is /sys/block/sda/device/model. I'll expand this info in an answer. Commented May 3, 2016 at 20:01
  • 1
    Based on reading the other Q, I'm not sure how to address this. It seems to me that sysfs is growing, so do we want to tag this Q with a specific kernel version number so that it's answerable? Also, does /proc have the same driver interfaces that Tim Bird refers to? Commented May 4, 2016 at 10:54

2 Answers 2

Reset to default
1

Sysfs is not at all a subset of procfs. They serve different purposes, see the answers to What is the difference between procfs and sysfs?.

Improve this answer
1
  • The fact that two sets serve different purposes does not mean that one is not a subset of the other. E.g. the set of records in the stock database at my local chain grocery store is (in principle!) a strict subset of those present in the stock database at the store's company's headquarters. The local store's database is for the store manager's routine usage, and is not routinely directly accessed by the company's data scientists or central managers. The database at the HQ is for the routine direct use of the latter two groups, and likely not accessible at all by my local store's manager. Commented May 3, 2016 at 20:19
0

No, it is not a strict subset. It is not even a subset.

Here is a demonstration, on a desktop PC running a major GNU/Linux distribution without any customisations that should affect the result, that there is at least one datum present in sysfs that is not present in procfs: 

$ grep -ir `cat /sys/block/sda/device/model | cut -f1 -d' '` /sys 2>/dev/null /sys/devices/pci0000:00/0000:00:1f.2/ata3/host2/target2:0:0/2:0:0:0/model:SanDisk [...] Binary file /sys/devices/pci0000:00/0000:00:1f.2/ata3/host2/target2:0:0/2:0:0:0/vpd_pg83 matches $ grep -ir `cat /sys/block/sda/device/model | cut -f1 -d' '` /proc 2>/dev/null Binary file /proc/26887/task/26887/cmdline matches Binary file /proc/26887/cmdline matches

This also demonstrates, incidentally, that on that PC at least, the set of all data exposed by procfs is not a subset of the data exposed by sysfs.

Improve this answer