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?

  • 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. – Tom Hunt May 03 '16 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 :) –  May 03 '16 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. –  May 03 '16 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. –  May 03 '16 at 20:01
  • I see that Gilles has marked my question as a duplicate of What is the difference between procfs and sysfs?. That is an error on Gilles's part. Despite its title, neither that other question nor its answers address the existence (or not) of subset relationships obtaining between the information exposed by procfs and sysfs; mine does. –  May 04 '16 at 10:30
  • 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? – Jeff Schaller May 04 '16 at 10:54
  • @JeffSchaller, thanks. I appreciate your concern, but I think it's OK to leave the question as it is. Here's why. "It seems to me that sysfs is growing". sysfs is not a subset of procfs, so even if sysfs does keep growing then it will continue to not be a subset of procfs. At least, that's true as long as procfs doesn't grow to become a superset of sysfs, which currently seems very unlikely. And if that latter unlikely eventuality comes to pass, then hopefully someone will update this question with a new answer to say so. –  May 04 '16 at 21:32

2 Answers2

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?.

Community
  • 1
countermode
  • 7,533
  • 5
  • 31
  • 58
  • 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. –  May 03 '16 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.