5 ms·

Procfs: Processes as Files (1984) [pdf]

50 points by tanelpoder 6y ago

tanelpoder 6y ago
I was updating my Linux Process Snapper /proc sampling/profiling tool [1] and ended up curious about when did this concept (examining process state via reading special files) first show up. Back in 1984 already, pretty wild! And, according to Wikipedia, it was first meant to replace the usage of ptrace() syscall [2]. [1] https://tanelpoder.com/psnapper/ https://tanelpoder.com/psnapper/ [2] https://en.wikipedia.org/wiki/Procfs#UNIX_8th_Edition https://en.wikipedia.org/wiki/Procfs#UNIX_8th_Edition
mgerdts 6y ago
Wow, that's 7 years earlier than the paper with Roger Faulkner that I thought was the first. I guess this is the first reference in the Faulkner and Gomes paper. https://www.usenix.org/sites/default/files/usenix_winter91_faulkner.pdf https://www.usenix.org/sites/default/files/usenix_winter91_f...
- Isamu 6y ago
  That Faulkner paper also discussed differences with Plan9’s implementation of /proc
marcodiego 6y ago
UNIX idea of (almost) everything is a file is probably one of the reasons that made its concepts and quirks so long lived and why we have to deal with them even today. Although I agree with many of the points of "the UNIX hater's manual" no other OS came even close the influence that UNIX has had.
- pjmlp 6y ago
  Because none of the alternatives was free beer with source code as dessert. Everything is a file on UNIX until it isn't, when it comes to IPC and everything that came after Bell Labs was done with it.
Galanwe 6y ago
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)
- d23 6y ago
  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.
  - jbverschoor 6y ago
    Is rather have proper object interface to work with. Saves a lot of parsing
    - viraptor 6y ago
      You could have object interface on procfs. I think Solaris used a lot of binary files there.
    - bayindirh 6y ago
      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.
      - jbverschoor 6y ago
        Streams should be used for that.. streams. Structures should be used for structured data.
rektide 6y ago
one of the things I used to really like about js is that processes were often objects. need to get a file? make an XMLHTTPRequest object, give it some instructions, & watch it as it progresses. Unfortunately promises have utterly ruined everything about these everything-is-an-object days, in practice. Now you stack up a whole bunch of constructions options & create a Fetch promise, which exposes nothing, says nothing, reports nothing. It's safer & yeah it's better too, more explicit & intentional, but heavens, adding back progress, adding back abort, & the general complete lack of common ways to live manage your transfer progress: everyone has their own means of using & harvesting control, where-as previously the XHR had control built in. Promises really are processes. They're not just an abstract future value, they're a thing representing the work too. Alas while once upon a time js had a design sensibility to expose pieces & control alike a process exposing itself as files, today a way more top-down non-first-class way isn't just dominating, it's totally taken over the language. Some ultra-conservative hardline mindsets made it through with promises, such as a) that they had to be accessed asynchronously, for no real reason other than great great great fear of the user (resulting in them being almost ideal, but actually alas unsuitable to work as things like AbortSignals & many other level-triggered systems that they very very closely resemble), and b) that promise handlers don't get to see their handlee/triggered. There's a whole host of design decisions that very outspoken very controlling people put into the languages reflecting their biases. I don't think the were wrong, but there's a ton of possibility space & openness & expressiveness that just got dumped, deliberately that, yes, probably would have slowed down uptake had some confusion, but which sadly really constrains how good we are at modelling & thinking about long running things very harshly.

50 points by tanelpoder 6y ago

I was updating my Linux Process Snapper /proc sampling/profiling tool [1] and ended up curious about when did this concept (examining process state via reading special files) first show up. Back in 1984 already, pretty wild! And, according to Wikipedia, it was first meant to replace the usage of ptrace() syscall [2]. [1] https://tanelpoder.com/psnapper/ https://tanelpoder.com/psnapper/ [2] https://en.wikipedia.org/wiki/Procfs#UNIX_8th_Edition https://en.wikipedia.org/wiki/Procfs#UNIX_8th_Edition

mgerdts 6y ago

Wow, that's 7 years earlier than the paper with Roger Faulkner that I thought was the first. I guess this is the first reference in the Faulkner and Gomes paper. https://www.usenix.org/sites/default/files/usenix_winter91_faulkner.pdf https://www.usenix.org/sites/default/files/usenix_winter91_f...

Isamu 6y ago
That Faulkner paper also discussed differences with Plan9’s implementation of /proc

marcodiego 6y ago

UNIX idea of (almost) everything is a file is probably one of the reasons that made its concepts and quirks so long lived and why we have to deal with them even today. Although I agree with many of the points of "the UNIX hater's manual" no other OS came even close the influence that UNIX has had.

pjmlp 6y ago
Because none of the alternatives was free beer with source code as dessert. Everything is a file on UNIX until it isn't, when it comes to IPC and everything that came after Bell Labs was done with it.

Galanwe 6y ago

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)

d23 6y ago
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.
- jbverschoor 6y ago
  Is rather have proper object interface to work with. Saves a lot of parsing
  - viraptor 6y ago
    You could have object interface on procfs. I think Solaris used a lot of binary files there.
  - bayindirh 6y ago
    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.
    - jbverschoor 6y ago
      Streams should be used for that.. streams. Structures should be used for structured data.

rektide 6y ago

one of the things I used to really like about js is that processes were often objects. need to get a file? make an XMLHTTPRequest object, give it some instructions, & watch it as it progresses. Unfortunately promises have utterly ruined everything about these everything-is-an-object days, in practice. Now you stack up a whole bunch of constructions options & create a Fetch promise, which exposes nothing, says nothing, reports nothing. It's safer & yeah it's better too, more explicit & intentional, but heavens, adding back progress, adding back abort, & the general complete lack of common ways to live manage your transfer progress: everyone has their own means of using & harvesting control, where-as previously the XHR had control built in. Promises really are processes. They're not just an abstract future value, they're a thing representing the work too. Alas while once upon a time js had a design sensibility to expose pieces & control alike a process exposing itself as files, today a way more top-down non-first-class way isn't just dominating, it's totally taken over the language. Some ultra-conservative hardline mindsets made it through with promises, such as a) that they had to be accessed asynchronously, for no real reason other than great great great fear of the user (resulting in them being almost ideal, but actually alas unsuitable to work as things like AbortSignals & many other level-triggered systems that they very very closely resemble), and b) that promise handlers don't get to see their handlee/triggered. There's a whole host of design decisions that very outspoken very controlling people put into the languages reflecting their biases. I don't think the were wrong, but there's a ton of possibility space & openness & expressiveness that just got dumped, deliberately that, yes, probably would have slowed down uptake had some confusion, but which sadly really constrains how good we are at modelling & thinking about long running things very harshly.