11

Im working on an app to collect and send various bits of system info (partition space/free, laptop battery info, etc). Im not having much success getting this information in the form of direct c++ api.. though its all available via files in /proc (or similar).

So - I'm wondering whether reading/parsing these files in my c++ app is the appropriate way to get this info or should I keep trying to discover APIs? ( NOTE: I am working with statvfs ).

So far it looks like it's easier to gather this sort of info in Win32. Seems strange.

Chris Gerken
  • 16,221
  • 6
  • 44
  • 59
ethrbunny
  • 10,379
  • 9
  • 69
  • 131
  • The procinfo source has some hints as to how to parse each file http://svn.tabris.net/repos/procinfo-ng/trunk/ – pmr Oct 06 '11 at 23:50

3 Answers3

7

It is best practice by far to stick with an API in the following order of precedence.

  • Your language API (not much help for you here, but say for strings, a C99 string function is better to use than a library string facility specified by a Posix or other OS standard.)

  • Posix operating software APIs

  • Documented kernel API's

  • Undocumented kernel APIs (at least these will break, say, ioctl users if they change, so they probably won't change)

  • /proc

  • /dev/kmem, /dev/mem

There is no reason to believe that /proc trolling will be portable or even the same from release to release. Not every system will even have a /proc mounted!

Having said all that, it is much easier to just scrape stuff off of /proc and if it's the only available interface then you should go ahead and use it.qa

Finally, the ordering of the last two isn't completely clear, because /proc isn't available for a post-mortem kernel crash dump analysis, but tools that can peek in the core dump will still work.

DigitalRoss
  • 143,651
  • 25
  • 248
  • 329
  • 1
    There *is* no other interface than /proc for a lot of information in Linux. And for version changes, *pay attention* to /proc outputs that contain a version ID. And in multi-column /proc outputs don't assume it won't get more columns in future! – Zan Lynx Jan 10 '11 at 20:58
  • And that's why I included it in the list of places to go. – DigitalRoss Jan 10 '11 at 21:05
  • 1
    +1 but I'd add above `/proc` utilities in the repository which use `/proc` in the correct system-specific way (such as `procps`, `systune`, `linuxinfo`) –  Oct 06 '11 at 23:15
  • procfs **is** a [documented](http://man7.org/linux/man-pages/man5/proc.5.html) [kernel API](https://www.kernel.org/doc/Documentation/filesystems/proc.txt), so it should be above the "Undocumented kernel APIs" line in your list. – user1643723 Feb 22 '17 at 09:32
1

I though that /proc was the API (everything is a file...)

AProgrammer
  • 51,233
  • 8
  • 91
  • 143
0

As you have noticed, a lot of Linux systems information is in /proc. And you're correct that there often isn't a C API for retrieving that information (though there is usually a shell command if you're inclined to stick with bash instead of C++). In the worst-case scenario, you might be stuck parsing through /proc, though you might be able to get some sample code in the form of open-source shell commands for the particular item you want.

chrisaycock
  • 36,470
  • 14
  • 88
  • 125
  • I guess I just want "someone who knows" to say "there aint no stinkin' api for that". Im fine with parsing the various files if that's what is assumed to be correct. – ethrbunny Jan 10 '11 at 20:22
  • @jyeargers Most tasks have no stickin' API. Sample code from open-source projects are usually the way forward. (Or just `strace` the shell command you want to emulate and see what files it opens if that's all you need.) – chrisaycock Jan 10 '11 at 20:25