On Mon, Sep 25, 2017 at 8:16 AM, Clem Cole <clemc@ccc.com> wrote:


On Mon, Sep 25, 2017 at 8:07 AM, Norman Wilson <norman@oclsc.org> wrote:
​...​

I too am saddened to see such a retrograde step, but perhaps
I'm biased.  When I arrived in 1127, the kernel had /proc but
still had ptrace as well.  Why?  Because no one was brave enough
to wade into sdb and adb.

​...


I can sympathize with FreeBSD excuse someone cited elsewhere,
that nobody used the code so it should go--I'm always in favour
of improving programs by chopping sutff out--but I think the
decision here was backwards.  The proper answer would have been
to teach ps et al to use /proc, not to invent a new complex of
system calls.
​+1 that was my point.   If the application code had been available @ UCB earlier before the proliferation,
I think and /proc has been part of 4.2 or at least 4.3 not 4.4, I think there would have been a better chance
of it being used.

I also agree about garbage collection, but this is a case where the right solution would have been to try to get people to use the new interface.​   The problem was ptrace was 'good enough' and there was no incentive so no one did it.

In the case of procfs and FreeBSD, the issues were more complicated and nuanced. The original /proc code came from 4.4BSD, and interacted with a number of kernel subsystems. These subsystems were undergoing evolution at the time (including a rather concerted rewrite of the VM to unify the buffer cache). This churn there lead to inevitable changes being needed to procfs to keep up with the new interfaces and such. Over time, there grew the feeling that there some something quite wrong with procfs (rightly or wrongly). There was a belief there were a number of unanticipated security issues that were lingering in the code, but due to the changes not only in API to the other sub-systems, but also in semantics. Kernel hackers that studied the problem came away with an uneasy feeling, but nothing actionable. This was the back-drop that slowed its adoption into new utilities in the FreeBSD tree and kept people from wanting to push it further until these misgivings could be explored and addressed. In the end, it was easier to have a better understood code base (ptrace) that had an icky interface over one that was cleaner, but that had clouds over it. As fewer and fewer things used /proc, it became easier and easier to ignore, and at some point people started worrying that this code that was basically unused could be an attack vector on the systems, so it was retired.

It's been a number of years since all this went down, so my memory of it may be clouded. Plus, I was FreeBSD's security officer for a time, and I'm purposely not going back to my notes from the time since I promised to keep all that business confidential (and I'm not exactly sure where they are). So, there may be the odd detail wrong, or imprecision of language, but the main thrust is there: new with issues that are hard to quantify, but have potential for embarrassment should the misgivings bear fruit militates for staying with the old. It also didn't help there were no strong supporters willing to stand behind the code, which didn't help with the misgivings. Had it not exited the tree then, the push to MP would have counted it as a casualty absent a strong maintainer to make it MP safe.
 
Mark Litton's thesis was DBX which was being written when 4.2 was being developed.   If Mark had had /proc the simplicity would have been compelling.   But once the code was written, it was hard to justify switching.

It's my same observation about why Fortran still is #1 in the high end of the business.   It's just not interesting to replace it.

So what I'm asking us to try to do, is not just look at the technology in a vacuum.   Why was it not interesting to /proc for BSD.   Clearly, Linux added it (differently than Eighth Edition of course and the 4.4 implementation was much more like V8 that Linux would settle).   People did do the work to use it.

So why did *BSD not bring those versions of the utilities back?

My >>guess<< while they had added some things (like /proc) it was different again and we got into the BSD != Linux stuff - which has been the UNIX war all over again.

There might have been a bit of that too, but it was background noise. The misgivings about the code, and the lack of a strong maintainer to cope with the misgivings drive the decision. No one was there to bar the door when the grim reaper came.

Sigh....


 

I dislike how Linux has tossed information about processes and
other system-related data into the same namespace (and now that
there is /sys as well as /proc, I wonder whether it's time to
divorce them, or even to move /proc into /sys/proc), but the
general direction of moving things into the file system makes
sense.
I agree, but let's just create a /sys/proc namespace and try to be consistent.  Here is a case where I wish *BSD would just pick up the Linux solution and be done with it.  It's not worth arguing.,​
 

The Linux solution has two barriers to entry though: GPL means the code can't be shared and even if it could the radically different structures of the kernel means little could be shared. So it would be, at best a compatible implementation. There's bits of /proc for linux in the FreeBSD Linux execution environment, but not the full thing.
 
I have some qualms about adding more and more code to
the kernel that just does string processing (making the kernel
bigger and more complicated, and widening the attack surface
for bad guys),
​+1​

 
though; maybe most of that stuff belongs not in
the OS proper but in a user-mode program that reads /dev/mem
and presents as a file system.
​Agree although, I would love to see consistency and moving towards one namespace & associated API that we all used.​
 

I'm not so sure about that. I hate /dev/kmem solutions to problems, or any solution that has to have many round-trips between the kernel and userland, especially on MP systems where locking and consistency issues clash with the desire for maximum performance...

Warner