Hacker News Reader

Comment by Galanwe | Hacker News Reader

On the comments that glorify procfs as a great example of "everything if a file", I'm not sure that's how everyone sees procfs.

To me, it has always been a sort of hackish/no hassle way of exposing some kernel interface that would not fit/be too annoying to provide as syscalls (not to mention there's a limit to the number of syscalls).

I would much more prefer a sysctl-like interface (i.e. a single, generic, syscalls to get process metadata).

As a side note, most BSDs moved (or are moving) away from procfs, for this very same reason (overused, too much pressure on the VFS, loose format, etc)

View on HN

Really? I think it's fantastic to have access to that kind of information from my shell. I've certainly used it for debugging live systems. Sure I could still use something like lsof and have it monkey around with the extra syscalls, but it's just really cool and useful to be able to use it with one less binary.

Is rather have proper object interface to work with. Saves a lot of parsing

You could have object interface on procfs. I think Solaris used a lot of binary files there.

Hacking a small pipeline starting with cat always beats having to write a code to parse something unintelligible at first sight IMHO.

At the end of the day, first one is always faster.

Streams should be used for that.. streams.

Structures should be used for structured data.

I don't see a reason for /proc/meminfo or /proc/cpuinfo to be a stream. Similarly /proc/$pid/{cmdline,cgroup,mounts,..} to be streams.

/proc is a very fine interface for getting realtime basic information about a process. Maybe we should leave it as it is and stop abusing well matured interfaces?

I see red when Chrome uses intentionally broken symbolic links to store information on a system for example.

It's not really harmful as long as it's just some shell programs here and there that use it. The problem is when everything starts to rely on it.

Hell, in linux, the dynamic linker (ld-linux.so) depends on procfs to expands ELF variables (e.g. $ORIGIN, which requires the path to the current program being executed, which is retrieved from procfs). It's gone _way_ too far!

Now it does not mean that an other interface would be ugly/annoying to use from the shell.

`sysctl` for instance is quite convenient to use from the shell, and the hierarchical variables that it accepts could very well mirror what procfs exposes.

Something like

`$ sysctl proc.42.environ` <=> `$ cat /proc/42/environ`

I feel Solaris really got this right with its p* commands, e.g. pargs -e 42 or just penv 42 to mirror your example. Whilst in practice they may use a procfs they could use other backends if implemented on other systems without or with a differing procfs. These commands are a much cleaner interface IMHO.

Reply on news.ycombinator.com