Hacker News Reader

Comment by pjmlp | Hacker News Reader

Procfs appeared originally on UNIX, see USENIX paper.

And BSDs removed it, deeming it a security risk.

Personally, I don’t like that it’s more of parsing text files to get a number, when you could have functions returning structs (of variable length, to get extensibility, while preserving backwards compatibility).

Not just BSDs; no major operating system other than Linux uses procfs anymore.

Solaris has had procfs for years.

Solaris is a history at this point.

Oracle and Fujitsu still sell and support it.

Really? Tell that oxide computers...well it's not Solaris but Illumos.

Sure, but Linux is also on more devices than any other OS in the world.

Your statement would be more damning it Linux was a minority player or on the decline, but that's not the case.

Procfs seems... fine, really.

Being pedantic, isn't Minix more widespread because Intel embedded it in CPUs?

Also most Linux machines, like phones, also contain instances of things like SEL4, often a couple of them.

And Linux... well, it managed to accumulate a lot of historical baggage for something that young. Device numbers are another example.

Nearly 30 years seems like plenty of time?

Many projects manage to accumulate plenty of tech debt in 30 months, without being a deliberate work-alike reimplementation of an existing system.. which I suspect means you're already starting with a certain amount of baggage.

A fair assessment, but at the end of the day it is all just a stream of bits, bits packed into a into a structure, how do you know the structure?, how do you know how wide each part is? or bits packed into an array of encoded bytes. what is the encoding? how do you parse it?

The array of encoded bytes despite it's complexity overhead has an advantage in that is lays on the human visible side of computing, that part of computers designed for the human to use. I have to admit more often than not I prefer to eat the overhead and have an interface that I can see.

The BSD approach at the time was to require setuid access for programs like ps to be able to read the kernel memory space via /dev/kmem to produce a running process list.

That is infinitely more stupid than procfs.

The stupidity of that is orthogonal to whether to use procfs or another sane, but less plan9 approved design like a syscall interface or an ioctl.

I'm reminded of another thing that used to be file based but moved away, and towards syscalls: random number generation. One criticism of a /dev/random approach I've seen is that open(2) could have some fringe error case (descriptor table too big?), and you don't want your secure RNG to bail on you. In particular lazy initialization of a secure RNG where the caller may not be able to check for errors.

Overall it's far more universal interface, you app "just" needs to parse relatively simple texfiles instead of api call per data type.

The text format is a problem on its own tho, "procfs but serialized using single format" would IMO be a best middle ground between tying your app to essentially kernel headers and parsing a bunch of random textfiles

Reply on news.ycombinator.com