The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane")
@ 2019-06-25  2:27 Kirk McKusick
  0 siblings, 0 replies; 13+ messages in thread
From: Kirk McKusick @ 2019-06-25  2:27 UTC (permalink / raw)
  To: ron minnich; +Cc: TUHS main list

> From: ron minnich <rminnich@gmail.com>
> To: TUHS main list <tuhs@minnie.tuhs.org>
> Subject: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and
>         arcane")
> Message-ID:
>         <CAP6exYJshbA5HxOJ_iM21Cs0Y4vGfLuFigXxh4WTeqbZreY8UA@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
> 
> I always wondered who wrote this, anyone know? I have my suspicions but ...
> 
> ".SH BUGS
> .I Ptrace
> is unique and arcane; it should be replaced with a special file which
> can be opened and read and written.  The control functions could then
> be implemented with
> .IR ioctl (2)
> calls on this file.  This would be simpler to understand and have much
> higher performance."
> 
> it's interesting in the light of the later plan 9 proc interface.
> 
> ron

The manual pages were not yet under SCCS, so the best time gap that I
can give you is that the above text was added between the release of
3BSD (Nov 1979) and 4.0BSD (Nov 1980). Most likely it was Bill Joy
that made that change.

	Kirk McKusick

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane")
  2019-06-26  1:03       ` ron minnich
  2019-06-26  1:12         ` George Michaelson
@ 2019-06-26 15:41         ` Theodore Ts'o
  1 sibling, 0 replies; 13+ messages in thread
From: Theodore Ts'o @ 2019-06-26 15:41 UTC (permalink / raw)
  To: ron minnich; +Cc: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane")
  2019-06-26  1:12         ` George Michaelson
@ 2019-06-26  1:32           ` Noel Hunt
  0 siblings, 0 replies; 13+ messages in thread
From: Noel Hunt @ 2019-06-26  1:32 UTC (permalink / raw)
  To: George Michaelson; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 3038 bytes --]

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@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@gmail.com> wrote:
> >
> > On Tue, Jun 25, 2019 at 5:46 PM Larry McVoy <lm@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.
>

[-- Attachment #2: Type: text/html, Size: 4471 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane")
  2019-06-26  1:03       ` ron minnich
@ 2019-06-26  1:12         ` George Michaelson
  2019-06-26  1:32           ` Noel Hunt
  2019-06-26 15:41         ` Theodore Ts'o
  1 sibling, 1 reply; 13+ messages in thread
From: George Michaelson @ 2019-06-26  1:12 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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@gmail.com> wrote:
>
> On Tue, Jun 25, 2019 at 5:46 PM Larry McVoy <lm@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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane")
  2019-06-26  0:46     ` Larry McVoy
  2019-06-26  0:56       ` Rob Pike
@ 2019-06-26  1:03       ` ron minnich
  2019-06-26  1:12         ` George Michaelson
  2019-06-26 15:41         ` Theodore Ts'o
  1 sibling, 2 replies; 13+ messages in thread
From: ron minnich @ 2019-06-26  1:03 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

On Tue, Jun 25, 2019 at 5:46 PM Larry McVoy <lm@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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane")
  2019-06-26  0:46     ` Larry McVoy
@ 2019-06-26  0:56       ` Rob Pike
  2019-06-26  1:03       ` ron minnich
  1 sibling, 0 replies; 13+ messages in thread
From: Rob Pike @ 2019-06-26  0:56 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]

I have no informed opinion on Linux's /proc.

-rob


On Wed, Jun 26, 2019 at 10:46 AM Larry McVoy <lm@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@gmail.com> wrote:
> >
> > > On Tue, Jun 25, 2019 at 12:34 PM Norman Wilson <norman@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
>

[-- Attachment #2: Type: text/html, Size: 3074 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane")
  2019-06-26  0:37   ` Rob Pike
@ 2019-06-26  0:46     ` Larry McVoy
  2019-06-26  0:56       ` Rob Pike
  2019-06-26  1:03       ` ron minnich
  0 siblings, 2 replies; 13+ messages in thread
From: Larry McVoy @ 2019-06-26  0:46 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

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@gmail.com> wrote:
> 
> > On Tue, Jun 25, 2019 at 12:34 PM Norman Wilson <norman@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 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane")
  2019-06-25 23:52 ` ron minnich
@ 2019-06-26  0:37   ` Rob Pike
  2019-06-26  0:46     ` Larry McVoy
  0 siblings, 1 reply; 13+ messages in thread
From: Rob Pike @ 2019-06-26  0:37 UTC (permalink / raw)
  To: ron minnich; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

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@gmail.com> wrote:

> On Tue, Jun 25, 2019 at 12:34 PM Norman Wilson <norman@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
>

[-- Attachment #2: Type: text/html, Size: 1833 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane")
  2019-06-25 19:33 Norman Wilson
  2019-06-25 19:42 ` Bakul Shah
  2019-06-25 20:35 ` Clem Cole
@ 2019-06-25 23:52 ` ron minnich
  2019-06-26  0:37   ` Rob Pike
  2 siblings, 1 reply; 13+ messages in thread
From: ron minnich @ 2019-06-25 23:52 UTC (permalink / raw)
  To: Norman Wilson; +Cc: The Eunuchs Hysterical Society

On Tue, Jun 25, 2019 at 12:34 PM Norman Wilson <norman@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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane")
  2019-06-25 19:33 Norman Wilson
  2019-06-25 19:42 ` Bakul Shah
@ 2019-06-25 20:35 ` Clem Cole
  2019-06-25 23:52 ` ron minnich
  2 siblings, 0 replies; 13+ messages in thread
From: Clem Cole @ 2019-06-25 20:35 UTC (permalink / raw)
  To: Norman Wilson; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

On Tue, Jun 25, 2019 at 7:34 PM Norman Wilson <norman@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.

[-- Attachment #2: Type: text/html, Size: 2923 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane")
  2019-06-25 19:33 Norman Wilson
@ 2019-06-25 19:42 ` Bakul Shah
  2019-06-25 20:35 ` Clem Cole
  2019-06-25 23:52 ` ron minnich
  2 siblings, 0 replies; 13+ messages in thread
From: Bakul Shah @ 2019-06-25 19:42 UTC (permalink / raw)
  To: Norman Wilson; +Cc: tuhs

On Jun 25, 2019, at 12:33 PM, Norman Wilson <norman@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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane")
@ 2019-06-25 19:33 Norman Wilson
  2019-06-25 19:42 ` Bakul Shah
                   ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Norman Wilson @ 2019-06-25 19:33 UTC (permalink / raw)
  To: tuhs

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane")
@ 2019-06-25  1:08 ron minnich
  0 siblings, 0 replies; 13+ messages in thread
From: ron minnich @ 2019-06-25  1:08 UTC (permalink / raw)
  To: TUHS main list

I always wondered who wrote this, anyone know? I have my suspicions but ...

".SH BUGS
.I Ptrace
is unique and arcane; it should be replaced with a special file which
can be opened and read and written.  The control functions could then
be implemented with
.IR ioctl (2)
calls on this file.  This would be simpler to understand and have much
higher performance."

it's interesting in the light of the later plan 9 proc interface.

ron

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2019-06-26 15:42 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-25  2:27 [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane") Kirk McKusick
  -- strict thread matches above, loose matches on Subject: below --
2019-06-25 19:33 Norman Wilson
2019-06-25 19:42 ` Bakul Shah
2019-06-25 20:35 ` Clem Cole
2019-06-25 23:52 ` ron minnich
2019-06-26  0:37   ` Rob Pike
2019-06-26  0:46     ` Larry McVoy
2019-06-26  0:56       ` Rob Pike
2019-06-26  1:03       ` ron minnich
2019-06-26  1:12         ` George Michaelson
2019-06-26  1:32           ` Noel Hunt
2019-06-26 15:41         ` Theodore Ts'o
2019-06-25  1:08 ron minnich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).