Hacker News Reader

Comment by deepsun | Hacker News Reader

To me it actually sounds like a better approach than blindly following "everything is a file" mantra.

What's blind about it? Reading files is nicer than parsing ps output or needing to write native code over a syscall.

Trying to parse the output of several procfs files isn't as easy as it looks. The per-pid maps file for one (smaps is even worse). Much better if I could just get a struct with all this information.

Asking DevOps to program for basic tasks. Cool story, bro.

I've not looked at kernel source but, when I had a task to read info from /proc it looked like a lot of info was just pack() in there. So my parsing was just done with unpack(). Mapping those values from things that could be found in existing userland tools.

One problem with reading /proc is that its impossible to get consistent view of the whole system because you are iterating the processes one by one, instead of getting snapshot of all the processes.

Is there an OS that provides the whole result of ps(1) or equivalent in one syscall? I was under the impression that it was ~always iteration based.

On NT you can get this sort of stuff through WMI, although I'll admit it's not entirely clear to me how that resolves internally

I guess my point/question was more - is whatever system/library call you'd use atomic? There's technically no reason the system couldn't have a syscall that returns a full data structure of process info for as many processes as are in scope and guarantee that it's a perfect atomic snapshot of exactly how the process table looked when that call returned, but I'd want to be very confident and have explicit documentation promising as much before I depended on it.

The problems are: "what file?", "what format?", "merge data from multiple files".

Not sure if relevant to this discussion, but here's the problems I've experienced working with files for system devices:

[1] here's just a discovery of a logitech mouse receiver, notice that it touches:

    * /sys/class/*
    * /sys/module/*
    * /sys/class/hidraw/*/device/driver

I must take care that each dir might not be present, symlinks may be dangling, and access to multiple files is not atomic.

It would be much easier and stable using just one SQLite query, for example.

[1] https://github.com/Lekensteyn/ltunify/blob/master/ltunify.c#...

I'm totally with you for processes should probably use glibc/platform API calls, but procfs is nothing short of brilliant and a great validation of the power of the "everything is a file".

Except that any process that has obtained root (through a security flaw or otherwise) can extremely easily hide itself, as shown here.

I will admit that it's likely that the same thing could be done with loadable kernel modules, that said.

Reply on news.ycombinator.com