26 Jun
2019
26 Jun
'19
1:33 a.m.
It's interesting that this comment about ptrace was written
as early as 1980.
Ron Minnich's reference to Plan 9 /proc misses the mark, though.
By the time Plan 9 was written, System V already had /proc; see
https://www.usenix.org/sites/default/files/usenix_winter91_faulkner.pdf
And as the authors say, the idea actually dates back to Tom Killian's
/proc in Research UNIX. I don't know when Tom's code first went
live, but I first heard about it by seeing it in action on my first
visit to Bell Labs in early 1984, and it was described in public in
a talk at the Summer 1984 USENIX conference in Salt Lake City.
I cannot quickly find an online copy of the corresponding paper;
pointers appreciated. (Is there at least an online index of BTL
CSTRs? The big search engine run by the place that still has
some 1127 old-timers can't find that either.)
As for ptrace itself, I heartily agree that /proc made it obsolete.
So did everyone else in 1127 when I was there, but nobody wanted
to update adb and sdb, which were big messes inside. So I did,
attempting a substantial internal makeover of adb to ease making
versions for different systems and even cross-versions, but just
a quick hack for sdb.
Once I'd done that and shipped the new adb and sdb binaries to
all our machines, I removed the ptrace call from the kernel.
It happened that in the Eighth (or was it Ninth by then? I'd
have to dig out notes to find out) Edition manual, ptrace(2)
was on two facing pages. To celebrate, I glued said pages
together in the UNIX Room's copy of the manual.
Would it were so easy to take out the trash today.
Norman Wilson
Toronto ON
26 Jun
26 Jun
1:42 a.m.
On Jun 25, 2019, at 12:33 PM, Norman Wilson <norman(a)oclsc.org> wrote:
It's interesting that this comment about ptrace was written
as early as 1980.
Ron Minnich's reference to Plan 9 /proc misses the mark, though.
By the time Plan 9 was written, System V already had /proc; see
https://www.usenix.org/sites/default/files/usenix_winter91_faulkner.pdf
And as the authors say, the idea actually dates back to Tom Killian's
/proc in Research UNIX. I don't know when Tom's code first went
live, but I first heard about it by seeing it in action on my first
visit to Bell Labs in early 1984, and it was described in public in
a talk at the Summer 1984 USENIX conference in Salt Lake City.
I cannot quickly find an online copy of the corresponding paper;
pointers appreciated. (Is there at least an online index of BTL
CSTRs? The big search engine run by the place that still has
some 1127 old-timers can't find that either.)
http://lucasvr.gobolinux.org/etc/Killian84-Procfs-USENIX.pdf
2:35 a.m.
On Tue, Jun 25, 2019 at 7:34 PM Norman Wilson <norman(a)oclsc.org> wrote:
It's interesting that this comment about ptrace
was written
as early as 1980.
Indeed - that seems to be really strange. I wonder of the Man page was
written later.
I don't know when Tom's code first went
live, but I first heard about it by seeing it in action on my first
visit to Bell Labs in early 1984, and it was described in public in
a talk at the Summer 1984 USENIX conference in Salt Lake City.
Ditto. The 84 paper was the first I knew about it but ....
It's possible Tom was messing with it before then. Joy spent a couple of
Summers in NJ but I've forgotten when. But if it was being talked
about/prototyped in the summer of '79, he might have known by 1980. But I
find that unlikely.
I really don't remember people going /proc crazy until after the '84 paper.
The other minor thing missing was the VFS/File System Switch layer. Peter
had not put FSS into Research 8.
What I don't remember is which came first Peter's work for Tom. The RFS
guys would use Peter's work for V.3. I used it something similar for EFS
after reading about it and the NFS/EFS are '85 USENIX. Somebody at Sun
did VFS, which was better than FSS, although later we came to conclusion
both had advantages and disadvantages and a true i-node interposition layer
was best so you could really want to do FS stacking. But by that time,
the damage was done, and people had gone FS crazy. Since Sun gave away
NFS and Peter's work was tied up in either Research 8 or V.3 (i.e. AT&T
licensing), VFS won.
5:52 a.m.
On Tue, Jun 25, 2019 at 12:34 PM Norman Wilson <norman(a)oclsc.org> wrote:
It's interesting that this comment about ptrace was written
as early as 1980.
Ron Minnich's reference to Plan 9 /proc misses the mark, though.
your comment about my comment misses the mark; I was not talking about
the origins of /proc. This is probably because I was not clear and
probably because few people realize that the plan 9 process debugging
interface was strings written and read to/from /proc/<pid>/[various
files], rather than something like ptrace.
The first time I saw that debug-interface-in-proc in plan 9, it made
me think back to the 4.1c bsd manual ptrace comment, and I wondered if
there was any path that led from this man page entry to the ideas in
the plan 9 methods.
I actually implemented the plan 9 debug model in linux back around
2007, but was pretty sure getting it upstream would never happen, so
let it die.
ron
6:37 a.m.
Peter Weinberger started and Tom Killian finalized a version of /proc for
the eighth edition that is ioctl-driven. It was done in the early 1980s. I
don't know where the idea originated.
In Plan 9, we (I?) replaced the ioctl interface, which was offensively
non-portable.
-rob
On Wed, Jun 26, 2019 at 10:01 AM ron minnich <rminnich(a)gmail.com> wrote:
On Tue, Jun 25, 2019 at 12:34 PM Norman Wilson
<norman(a)oclsc.org> wrote:
It's interesting that this comment about ptrace was written
as early as 1980.
Ron Minnich's reference to Plan 9 /proc misses the mark, though.
your comment about my comment misses the mark; I was not talking about
the origins of /proc. This is probably because I was not clear and
probably because few people realize that the plan 9 process debugging
interface was strings written and read to/from /proc/<pid>/[various
files], rather than something like ptrace.
The first time I saw that debug-interface-in-proc in plan 9, it made
me think back to the 4.1c bsd manual ptrace comment, and I wondered if
there was any path that led from this man page entry to the ideas in
the plan 9 methods.
I actually implemented the plan 9 debug model in linux back around
2007, but was pretty sure getting it upstream would never happen, so
let it die.
ron
6:46 a.m.
I'm curious what Rob and others think of the Linux /proc. It's string
based and it seems like it is more like /whatever_you_might_want.
The AT&T /proc that Faulkner worked on was much more narrow in scope,
in keeping with the Unix tradition. The linux /proc was both a way
to dig into kernel stuff and control kernel stuff, it was way broader.
On Wed, Jun 26, 2019 at 10:37:39AM +1000, Rob Pike wrote:
Peter Weinberger started and Tom Killian finalized a
version of /proc for
the eighth edition that is ioctl-driven. It was done in the early 1980s. I
don't know where the idea originated.
In Plan 9, we (I?) replaced the ioctl interface, which was offensively
non-portable.
-rob
On Wed, Jun 26, 2019 at 10:01 AM ron minnich <rminnich(a)gmail.com> wrote:
> On Tue, Jun 25, 2019 at 12:34 PM Norman Wilson <norman(a)oclsc.org> wrote:
> >
> > It's interesting that this comment about ptrace was written
> > as early as 1980.
> >
> > Ron Minnich's reference to Plan 9 /proc misses the mark, though.
>
> your comment about my comment misses the mark; I was not talking about
> the origins of /proc. This is probably because I was not clear and
> probably because few people realize that the plan 9 process debugging
> interface was strings written and read to/from /proc/<pid>/[various
> files], rather than something like ptrace.
>
> The first time I saw that debug-interface-in-proc in plan 9, it made
> me think back to the 4.1c bsd manual ptrace comment, and I wondered if
> there was any path that led from this man page entry to the ideas in
> the plan 9 methods.
>
> I actually implemented the plan 9 debug model in linux back around
> 2007, but was pretty sure getting it upstream would never happen, so
> let it die.
>
> ron
>
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
6:56 a.m.
I have no informed opinion on Linux's /proc.
-rob
On Wed, Jun 26, 2019 at 10:46 AM Larry McVoy <lm(a)mcvoy.com> wrote:
I'm curious what Rob and others think of the
Linux /proc. It's string
based and it seems like it is more like /whatever_you_might_want.
The AT&T /proc that Faulkner worked on was much more narrow in scope,
in keeping with the Unix tradition. The linux /proc was both a way
to dig into kernel stuff and control kernel stuff, it was way broader.
On Wed, Jun 26, 2019 at 10:37:39AM +1000, Rob Pike wrote:
Peter Weinberger started and Tom Killian
finalized a version of /proc for
the eighth edition that is ioctl-driven. It was done in the early 1980s.
I
don't know where the idea originated.
In Plan 9, we (I?) replaced the ioctl interface, which was offensively
non-portable.
-rob
On Wed, Jun 26, 2019 at 10:01 AM ron minnich <rminnich(a)gmail.com> wrote:
> On Tue, Jun 25, 2019 at 12:34 PM Norman Wilson <norman(a)oclsc.org>
wrote:
> >
> > It's interesting that this comment about ptrace was written
> > as early as 1980.
> >
> > Ron Minnich's reference to Plan 9 /proc misses the mark, though.
>
> your comment about my comment misses the mark; I was not talking about
> the origins of /proc. This is probably because I was not clear and
> probably because few people realize that the plan 9 process debugging
> interface was strings written and read to/from /proc/<pid>/[various
> files], rather than something like ptrace.
>
> The first time I saw that debug-interface-in-proc in plan 9, it made
> me think back to the 4.1c bsd manual ptrace comment, and I wondered if
> there was any path that led from this man page entry to the ideas in
> the plan 9 methods.
>
> I actually implemented the plan 9 debug model in linux back around
> 2007, but was pretty sure getting it upstream would never happen, so
> let it die.
>
> ron
>
--
---
Larry McVoy lm at mcvoy.com
http://www.mcvoy.com/lm
7:03 a.m.
On Tue, Jun 25, 2019 at 5:46 PM Larry McVoy <lm(a)mcvoy.com> wrote:
I'm curious what Rob and others think of the Linux /proc. It's string
based and it seems like it is more like /whatever_you_might_want.
it's very handy but quite difficult to work with programatically. The
output is convenient for humans to parse, not very nice for programs
to parse.
/proc on linux has no real standard way of outputting things. You get
tables, tuples, and lists and some stuff I can't classify
(/proc/execdomains, /proc/devices); and, in some cases, some files
give you more than one type of thing. Units are not clear for many
tables.
/proc on linux has far more than just process information, including
stuff that has nothing to do with processes (51 things on my current
linux, e.g. /proc/mounts).
Things are in many cases not self-describing, though lots of /proc
have this issue.
I do recall (possibly wrongly) at some point in the 2000s there was an
effort to stop putting stuff in /proc, but rather in /sys, but that
seems to have not worked out. /proc is just too convenient a place,
and by convention, lots of stuff lands there.
While I was at LANL we did experiment with having /proc come out as
s-expressions, which were nicely self describing, composable, easily
parsed and operated on, and almost universally disliked b/c humans
don't read s-expressions that easily. So that ended.
We've been reimplementing Unix commands in Go for about 8 years now
and dealing with all the variance in /proc on linux was a headache.
You pretty much need a different function for every file in /proc.
And all that said, it's handy, so hard to complain about too much.
7:12 a.m.
The lack of consistency in what you can READ in /proc makes it hard to
believe its useful in the "wide" -but I am sure specific things get
benefit from it, as an abstraction which makes code simple because
"its a file"
if you're WRITING into things in /proc, I think you own the pain be it
an ioctl() or anything else.
I see occasional shell scripts about turning on and off meta-state for
SCSI or SAS as "cat 0 >
/dev/somedir/some-model-of-abstraction/some-disk" and while I applaud,
I also wince. So easy to go wrong..
As a long-term user and non-developer, I'm sort of half a believer,
half not. Maybe if it had emerged before the great Schism(s) it would
be more normal? sane? understandable?
-G
On Wed, Jun 26, 2019 at 11:04 AM ron minnich <rminnich(a)gmail.com> wrote:
On Tue, Jun 25, 2019 at 5:46 PM Larry McVoy <lm(a)mcvoy.com> wrote:
I'm curious what Rob and others think of the Linux /proc. It's string
based and it seems like it is more like /whatever_you_might_want.
it's very handy but quite difficult to work with programatically. The
output is convenient for humans to parse, not very nice for programs
to parse.
/proc on linux has no real standard way of outputting things. You get
tables, tuples, and lists and some stuff I can't classify
(/proc/execdomains, /proc/devices); and, in some cases, some files
give you more than one type of thing. Units are not clear for many
tables.
/proc on linux has far more than just process information, including
stuff that has nothing to do with processes (51 things on my current
linux, e.g. /proc/mounts).
Things are in many cases not self-describing, though lots of /proc
have this issue.
I do recall (possibly wrongly) at some point in the 2000s there was an
effort to stop putting stuff in /proc, but rather in /sys, but that
seems to have not worked out. /proc is just too convenient a place,
and by convention, lots of stuff lands there.
While I was at LANL we did experiment with having /proc come out as
s-expressions, which were nicely self describing, composable, easily
parsed and operated on, and almost universally disliked b/c humans
don't read s-expressions that easily. So that ended.
We've been reimplementing Unix commands in Go for about 8 years now
and dealing with all the variance in /proc on linux was a headache.
You pretty much need a different function for every file in /proc.
And all that said, it's handy, so hard to complain about too much. 
7:32 a.m.
I thought there was a filesystem in Ninth Edition called
'/tbl' wherein various system related items could be read.
I have never seen it in operation but I'm sure I saw it
in the kernel code; it seemed to fulfill all the functions
of the non-process related information that Linux dumps
into /proc.
Am I perhaps mistaken about this?
On Wed, Jun 26, 2019 at 11:13 AM George Michaelson <ggm(a)algebras.org> wrote:
The lack of consistency in what you can READ in /proc
makes it hard to
believe its useful in the "wide" -but I am sure specific things get
benefit from it, as an abstraction which makes code simple because
"its a file"
if you're WRITING into things in /proc, I think you own the pain be it
an ioctl() or anything else.
I see occasional shell scripts about turning on and off meta-state for
SCSI or SAS as "cat 0 >
/dev/somedir/some-model-of-abstraction/some-disk" and while I applaud,
I also wince. So easy to go wrong..
As a long-term user and non-developer, I'm sort of half a believer,
half not. Maybe if it had emerged before the great Schism(s) it would
be more normal? sane? understandable?
-G
On Wed, Jun 26, 2019 at 11:04 AM ron minnich <rminnich(a)gmail.com> wrote:
On Tue, Jun 25, 2019 at 5:46 PM Larry McVoy <lm(a)mcvoy.com> wrote:
I'm curious what Rob and others think of the Linux /proc. It's string
based and it seems like it is more like /whatever_you_might_want.
it's very handy but quite difficult to work with programatically. The
output is convenient for humans to parse, not very nice for programs
to parse.
/proc on linux has no real standard way of outputting things. You get
tables, tuples, and lists and some stuff I can't classify
(/proc/execdomains, /proc/devices); and, in some cases, some files
give you more than one type of thing. Units are not clear for many
tables.
/proc on linux has far more than just process information, including
stuff that has nothing to do with processes (51 things on my current
linux, e.g. /proc/mounts).
Things are in many cases not self-describing, though lots of /proc
have this issue.
I do recall (possibly wrongly) at some point in the 2000s there was an
effort to stop putting stuff in /proc, but rather in /sys, but that
seems to have not worked out. /proc is just too convenient a place,
and by convention, lots of stuff lands there.
While I was at LANL we did experiment with having /proc come out as
s-expressions, which were nicely self describing, composable, easily
parsed and operated on, and almost universally disliked b/c humans
don't read s-expressions that easily. So that ended.
We've been reimplementing Unix commands in Go for about 8 years now
and dealing with all the variance in /proc on linux was a headache.
You pretty much need a different function for every file in /proc.
And all that said, it's handy, so hard to complain about too much. 
9:41 p.m.
On Tue, Jun 25, 2019 at 06:03:47PM -0700, ron minnich wrote:
I do recall (possibly wrongly) at some point in the 2000s there was an
effort to stop putting stuff in /proc, but rather in /sys, but that
seems to have not worked out. /proc is just too convenient a place,
and by convention, lots of stuff lands there.
When looking at linux's /proc, there are three broad categories of
stuff:
* Traditional process-specific files, in /proc/<pid>/...
* System configuration parameters, aka "sysctls", which are
in /proc/sys/...
* Other miscellaneous ad-hoc files
It's the last category where there has been a big push to only add new
files in /sys (aka sysfs), and in general the vast majority of new
files have been going into sysfs, and not into /proc. However, for
backwards compatibility reasons, all of the old ad-hoc /proc files
have stuck around.
The files in /sys and /proc/sys tend to be very discplined, in that
it's one value per file. That's both a good and bad thing. We don't
have a general, efficient, way of supporting files that return a
variable list of fields, especially if there is no obvious key.
(e.g., like /proc/mounts). And it's certainly the case that looking
at, say, /proc/scsi/scsi is much more conveient that iterating over
/sys/bus/scsi/devices and grabbing a huge number of tiny files to get
the same information.
This last is the usual reason where there is temptation by some
developers to add a new file in /proc, as opposed to adding several
dozen files (per device/process/network connection) in /sys and then
needing to promulgate a perl/python/go program to actually get a user
friendly status report out.
- Ted
2005
days inactive
2006
days old
10 comments
9 participants
participants (9)
-
Bakul Shah -
Clem Cole -
George Michaelson -
Larry McVoy -
Noel Hunt -
Norman Wilson -
Rob Pike -
ron minnich -
Theodore Ts'o