Linux c++: apis vs /proc files?

Question

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.

Instal

The procinfo source has some hints as to how to parse each file svn.tabris.net/repos/procinfo-ng/trunk – Broeder

Answer 1

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.

Creaturely

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! – Kazimir

And that's why I included it in the list of places to go. – Creaturely

+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) – Greatgranduncle

procfs is a documented kernel API, so it should be above the "Undocumented kernel APIs" line in your list. – Satinet

Answer 2

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

Confucian

Answer 3

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.

Nottinghamshire

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. – Instal

@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.) – Nottinghamshire