Why people have moved away from using <code>/proc</code> for everything

One of the great ideas in Unix is the /proc pseudo-filesystem (which comes from Research Unix). Initially used to expose processes (cf) as an alternative to ptrace(), it grew to encompass an increasing amount of general system information in some Unixes, such as Linux. In Linux, this has resulted in frequent use of general /proc files, but in Linux and in other Unixes, people are increasingly moving away from accessing information through /proc in favour of direct system calls. This isn't because /proc is a bad idea in theory. Instead, it's because there turn out to be some issues with /proc in practice, both about performance and about reliability.

The famous performance issue is that on Linux (and to a lesser extent elsewhere), a lot of information in /proc consists of binary numbers that are reported in text form. This requires the kernel to format all of these numbers to text and then consumers of /proc information will generally parse them back into binary. All of this consumes CPU time, especially if programs are reading /proc frequently (as they may be for performance metrics or other information). Text is convenient for easy consumption at one level but not necessarily optimal, which is why a lot of alternate interfaces transfer things in binary form.

A less obvious performance issue is the number of system calls and kernel work required to access information from /proc. When something is in a file in /proc, you have to open() the filename, read() the file, and close() it again (or perhaps leave the file open but reset things with lseek() before you read() again). All of these system calls and the accompanying kernel work (for example, to resolve filenames) add up over time. Modern interfaces to get this information such as sysctl() or sysinfo() give you things in a single system call, perhaps even a single system call for multiple pieces of information. Doing direct 'system calls' also opens up the possibility of accessing certain read only information entirely in user space (Linux does this for a very small set of system calls, mostly time related ones, but it could be expanded).

A bigger issue with retrieving information through /proc is reliability (and related to it, security). To start with, to access anything in /proc you have to be able to create a file descriptor; if you're out of file descriptors for some reason, your attempt to get the load average will fail. More seriously, so can your attempt to get some random numbers. This might happen through accident (including low file descriptor limits) or through a deliberate attack that seeks to glitch out something security sensitive. You also have to keep track of that file descriptor, close it when necessary, and so on, which can be a problem in a heavily threaded program (especially if it fork()s sometimes; the forked child might inherit in-flight open /proc file descriptors with nothing to close them).

If access to /proc or /dev is critical for things like secure random numbers, this has implications for things using chroot and similar security restrictions. If you set up a chroot environment, it needs to have at least some bits of /proc and /dev accessible in it. You also have to allow processes operating in your secure sandbox to open() files at all, which is a power you might want to discard in some contexts (for example, a web browser process that's only supposed to decode or compute some things). If you want to allow access to selected /proc based things but not open() in general, you're going to need some increasingly sophisticated system call filtering.

(/dev/random and /dev/urandom aren't quite /proc virtual files, but they suffer from the same issues with file descriptor use and exhaustion, security restrictions, and so on.)

Another reliability issue is getting various information about a process in a consistent, atomic manner. When information is split across multiple /proc/<pid> files, you might get inconsistent information since you have to make multiple read() calls to get it (even if you pre-open all of the files and then try to read() them all as fast as possible). The same thing can happen if it takes multiple read() calls to access a single file. Alternative system call interfaces for process information let the kernel provide a consistent view of everything you ask for.

All of this has pushed systems using /proc, especially Linux, into having an array of additional ways to access the same data. For example, pretty much every Unix now has some kind of system call to get randomness from the kernel (see Wikipedia's entropy-supplying system calls).

None of this makes the ideas of /proc wrong, and even the initial reality of /proc was a vast improvement over what came before (which was generally programs that fished around in raw kernel memory to read raw kernel data structures). And it remains genuinely useful to be able to extract this information in plain text from filesystem paths, because pretty much everything can open files and read plain text, including shell scripts. But it does go to show that practical reality can get messy.