On Sun, Sep 24, 2017 at 10:02 AM, ron minnich <rminnich@gmail.com> wrote:
ptrace replaces procfs? Wow, that's a disappointing turn of events. It's also against the flow of thought in the Unix community I knew in 1980. If somebody has any of the old ca-1980 BSD manuals, you should find a BUGS section on ptrace advocating a move to a file-system-like interface. I always assumed ken wrote that little note when he was visiting UCB -- anybody know? 
​Need to check the UCB SCCS deltas, but I doubt it.  Ken was there before ​/proc appeared in Eight Edition.
ptrace was a hack, I don't think Dennis was particularly happy with it.  It was sprt of considered a weak link. 


 

Plan 9 implements process debug via /proc, and several debuggers use that interface
​Yes, pretty much post Eight  Edition, /proc becomes the defacto interface.​
Looking back on the time, I think two things go in its way which were both more political than technical.
By the time it appears in the Research kernel, there is still not an agreed upon file system layering.   The vfs-layer would start to get argued about, but it wasn't there [ more in a minute ].

So file systems (like /proc) were still more ad-hoc interfaces.

Second because either edition was not released the same way eailier versions were, and AT&T was trying to use Summit as their IP release mechanism; it got caught in the 'UNIX Wars.'    I really think as much as BSD was making great strides, if the new features of Eight had been made available to BSD, many of them (like /proc) would have been integrated and if had been integrsated earilier, more of the BSD tools (like debugger, et al) would have relied on it and if that had occured; it would have been better integrated (like it is in Linux today).


 
​....

The file system model is powerful. The strace based on /proc was a few dozen lines.
​Amen... ​
 


​To me, the really important thing SMI did by giving away NFS, was to start the FS laying argument.   What we ended up with is not perfect, its a compromise (I wish the stacking model was better), but we started to have the discussion.​   But because of NFS, we ended up getting a lot of different file system options; which previously we did not have.   It made us really think through what were 'meta' functions that were FS independant, 'virtual' functions what span all FS implementasions, and what were 'physical' (implementation) specific file system functions. 

NFS really should be credited for forcing that clean up.

Similarly, a few of us tried (and failed) to have the process layer discussion -- consider the Locus vprocs work.   It's really too bad, we don't have that layer in any of the UNIX kernels today, it really make process control, migration, etc a lot cleaner; just as adding a file system layer did.

But that's a war, I fought and lost....