Does the hard drive need to be accessed or is everything done in memory? Basically I would like to constantly get updated values from meminfo and cpuinfo.
Do I need to reopen the file and then reread in order to get an updated value or can I just reread? I don't have access to a Linux install at the moment.
When you read from /proc, the kernel generates content on the fly. There is no hard drive involved.
What you're doing is similar to what any number of monitoring programs do, so I advise you to look at what they're doing. For example, you can see what top does:
strace top >/dev/null
The trace shows that top opens /proc/uptime, /proc/loadavg, /proc/stat and /proc/meminfo once and for all. For all these files except /proc/uptime, top seeks back to the beginning of the (virtual) file and reads again each time it refreshes its display.
Most of the data in /proc/cpuinfo is constant, but a few fields such as the CPU speed on some machines are updated dynamically.
The proc filesystem is documented in the kernel documentation, in Documentation/filesystems/proc.txt. If you get desperate about some esoteric detail, you can browse the source.
The /proc filesystem is a so-called "pseudo filesystem", meaning that (afaiu) there is no disk usage.
I'm not quite sure how this works at the lowest level, so I may be wrong, but here goes. If I run
f = open('/proc/meminfo')
f.read()
f.seek(0)
f.read()
I get two different outputs. Afaik, seek(0) only resets the read offset and it doesn't re-open the file. This suggests that re-reading a file is enough to get the new values.
That said, if you are developing for Linux, getting permanent access to Linux box seems a pretty logical thing to do...
virtual filesystem with pseudo filesystem. /proc is a pseudo filesystem. virtual filesystems (VFS) are explained in detail here
– chris
Feb 27 '11 at 14:22
The files are not stored on disk, but they are hooks to the kernel.
When you open a file (using fopen()), the kernel handles this job. It walks through the mountpoints, finds the apropriate driver to handle the request, and hands the task to that driver.
In the case of /proc, the file read request is passed to the internal "proc" system in the kernel. At the moment you read the file, it returns the value from memory.
A similar pattern also happens with the files in /dev. The kernel sees you open a dev-node with a certain device ID, and associates the IO stream with a particular driver that handles the request.
Basically I would like to constantly get updated values from meminfo and cpuinfo.
You can read the proc filesystem to read these values, or see if there are maybe other syscalls you can use for it. It will be a polling mechanism nevertheless, so there is always a certain system load involved.
The Unix filesystem is a single hierarchy, which Linux represents with its VFS subsystem. You mount filesystems on some nodes of the tree, for example when you plug a usb key. When you try to read a file the VFS looks which filesystem is mounted here, and forwards the request to the appropriate module. Some of the filesystems are backed by disk io, some represent kernel datastructures (/proc, /sys, debugfs, cgroups…), some are network based, some are memory-based (tmpfs), some are implemented in userland via FUSE, and can be backed by crazy stuff like databases, VCSes, ssh, archives and so on.
The /proc filesystem is a pseudo-filesystem. It is a convenient way of transferring memory from user space to kernel space and vice versa.
Each entry (file or directory) in the /proc directory is created by a part of the kernel. Each entry can be read and/or write. They can be opened from the userspace like any normal file. Entries are created in roughly the following manner (inside a kernel module):
procentry1 = create_proc_entry(path);
procentry1->read = read_function1;
procentry->write = write_function1;
So you roughly specify the path to be created, and functions that are to be called on read/write (You need one or both of them). The read function returns a string(like a file read call), while the write function takes a string. The corresponding read and write functions are called, whenever a program tries to read/write to the corresponding proc file path.
