The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] V6 networking & alarm syscall
@ 2019-01-12  4:14 Noel Chiappa
  0 siblings, 0 replies; 22+ messages in thread
From: Noel Chiappa @ 2019-01-12  4:14 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Dave Horsfall

    > As I dimly recall ... it returns the number of characters in the input
    > queue (at that time)

Well, remember, this is the MIT V6 PDP-11 system, which had a tty driver which
had been completely re-written at MIT years before, so you'd really have to
check the MIT V6 sources to see exactly what it did. I suspect they borrowed
the name, and basic semantics, from Berkeley, but everything else - who
knows.

This user telnet is from 1982 (originally), but I was looking at the final
version, which is from 1984; the use of the ioctl was apparently a later
addition. I haven't checked to see what it did originally for reading from the
user's terminal (although the earlier version also used the 'tasking'
package).

      Noel

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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-13 10:52 Paul Ruizendaal
@ 2019-01-13 15:39 ` Warner Losh
  0 siblings, 0 replies; 22+ messages in thread
From: Warner Losh @ 2019-01-13 15:39 UTC (permalink / raw)
  To: Paul Ruizendaal; +Cc: TUHS main list

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

On Sun, Jan 13, 2019 at 3:53 AM Paul Ruizendaal <pnr@planet.nl> wrote:

> > Where did you find the BBN TCP/IP stack?
>
> Easiest place to find it is the TUHS Unix Tree page:
> https://www.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP


And was the BBN V6 version ever ported to V7?

Several tapes of it survived in the CSRG archives, currently held by the
> Bancroft Library at Berkeley.
>

Are those online? Or an index? Google is failing me (or my google skillz
aren't mad this morning).


> A late version of the tcp/ip routines survived at the Stanford SAIL
> archives, currently online here:
> https://www.saildart.org/[IP,SYS]/
> (mixed in with sources for WAITS).
>

Now that's quite interesting. There's even a C compiler in [C,SYS].


> A much evolved version is in the BSD SCCS history:
> https://github.com/weiss/original-bsd/tree/master/sys/deprecated/bbnnet
> Note that the location ‘deprecated’ is where the code ended up. Back in
> 1985 it would have been in the normal build path, but SCCS does not
> preserve that.
>

I wonder if anybody has gone to the trouble of trying to recreate the
movement of these sys/deprecated things into real moves to deprecated
coupled with the commit that removed them from the files files, or if any
work has been done to make the tree buildable with these obscure things...

Warner

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

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

* Re: [TUHS] V6 networking & alarm syscall
@ 2019-01-13 10:52 Paul Ruizendaal
  2019-01-13 15:39 ` Warner Losh
  0 siblings, 1 reply; 22+ messages in thread
From: Paul Ruizendaal @ 2019-01-13 10:52 UTC (permalink / raw)
  To: TUHS main list

> Where did you find the BBN TCP/IP stack?

Easiest place to find it is the TUHS Unix Tree page:
https://www.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP

Several tapes of it survived in the CSRG archives, currently held by the Bancroft Library at Berkeley.

A late version of the tcp/ip routines survived at the Stanford SAIL archives, currently online here:
https://www.saildart.org/[IP,SYS]/
(mixed in with sources for WAITS).

A much evolved version is in the BSD SCCS history:
https://github.com/weiss/original-bsd/tree/master/sys/deprecated/bbnnet
Note that the location ‘deprecated’ is where the code ended up. Back in 1985 it would have been in the normal build path, but SCCS does not preserve that.

Paul




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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-12 18:16             ` Eric Allman
@ 2019-01-13  1:16               ` Madeline Autumn-Rose
  0 siblings, 0 replies; 22+ messages in thread
From: Madeline Autumn-Rose @ 2019-01-13  1:16 UTC (permalink / raw)
  Cc: TUHS main list

Where did you find the BBN TCP/IP stack?

Sent from my iPhone

On Jan 12, 2019, at 10:16, Eric Allman <tuhs@eric.allman.name> wrote:

>> Eric, please fill me in.
> 
> I have to admit that my memories are a bit fuzzy, but I'll try to fill
> in what I can.
> 
>> On 2019-01-12 9:20 AM, Clem Cole wrote:
>> ...
>> FWIW: Since I had been working networking at both CMU and Tek before I
>> came to UCB, one of the first things I did when I arrived in fall '81
>> was to install the Gurwitz BBN IP/TCP stack on 4.1 so we could run
>> Ethernet between the 3 CAD machines in Cory Hall to replace the use of
>> BerkNet over 9600 baud serial links (IIRC Eric Cooper, was involved with
>> that hack also).   When I had arrived, few machines at UCB were on LANS
>> and the need for ARPAnet style networking >>besides<< email was still
>> limited.  The way people connected to systems was their terminal was to
>> connect over serial links and we had a giant 'plugboard' that allowed
>> you patch your terminal into one of the systems [I wonder if there are
>> pictures of these somewhere in the UCB archives - it was quite something].
> 
> That it was.  When the INGRES group got our ARPAnet connection (VDH to
> LBL, as you mentioned) it was the only long-haul connection to campus
> that I know of.  Eric Schmidt had done BerkNET, but that was local mail
> and file copy only, and BerkNET mail didn't connect to ARPAnet mail, so
> there were "plugboard wars" over who got one of the two RS232
> connections we had available for outside users (this was out of a grand
> total of 16 connections on a DH-11, each at about $1000/port, iirc).  I
> was nominally responsible for the ARPAnet connection, so I had senior
> faculty on my case about how they all "needed" dedicated connections to
> their office (but of course they didn't want to pay for them).  This was
> the original inspiration for delivermail, which later became sendmail.
> 
>> We had three 780s in the CAD group in Cory and really did not like the
>> plugboard scheme. From my previous experience, I wanted something like
>> telnet or supdup, like we had been messing with at CMU and Tek.  Hence
>> my push to put the BBN code on the CAD systems and use an ethernet.   
>> Eric, please fill me in.   You must have been running the BBN code then
>> also, since Ing70 and then IngVax were the ArpaNet connection (via
>> a VHDH to the LBL IMP - UCB did not yet have its own IMP).   But I know
>> the CAD systems 4.1 networking stuff was done by me.
> 
> As I recall IngVax never had any ARPAnet service, and Ing70 was running
> the NCP code from San Diego, which could well have originated at BB&N,
> but I can't confirm that from memory.  Conversely, Ing70 was never on
> any "modern" networking technology such as 3Mbit ethernet (I don't think
> there were even NICs at that time).
> 
>> Its a little fuzzy now, but memory is that Bob Kriddle had run a Xerox 3
>> Meg cable in Cory, from my machine room over to the Ingres machine room
>> also; but I've forgotten the details.  BerkNet (i.e. serial links)
>> allowed email to flow on campus, but I'm thinking we were trying to make
>> that both more efficient and allow telnet/ftp [which might not have
>> happened until after the C/30 IMP was installed in Evan later).   [Since
>> all ARPAnet email followed through IngVax, Eric's history of dealing
>> with the header file format of the month in the old delivermail program
>> would force his writing sendmail - said history has been repeated here
>> and elsewhere previously].
> 
> Yes, modulo it being Ing70, not IngVax.
> 
>> But this thread got me thinking a little bit.   I've forgotten actual
>> LAN topology we had a UCB now. I know from the CAD hosts, we could talk
>> to the other hosts in our lab in Cory for sure, I want to say we could
>> talk to a few other hosts in Evans and Cory; as I know Sam would give me
>> code usually via some type of network connection, although sneaker-net
>> with 9-track tapes used a great deal too.   I want to say the connection
>> was over Kriddle's 3M Xerox cable (Eric do you remember what you had in
>> IngVax in those days).  I know we also a had real 10Meg cable in floor
>> our lab in Cory, plus at least one Xerox board on one of the systems,
>> another had a DEC interface in it, and Interlan boards in at least two
>> others another.   We must have even had a 3Com board in the third
>> system; as I remember hacking both the Interlan and 3Com drivers (I had
>> written a 3Com driver at Tek previous for VMS.  The Interlan board was
>> new, as was the DEC board; but I've forgotten what we got when).     The
>> original CAD 780 ('Coke')  must have had multiple interfaces in it, but
>> I really don't remember.
> 
> You would think I would remember more of the network situation around
> the INGRES project given that we had someone working on distributed
> databases (Ken Birman, now at Cornell I think, did something called
> COCANET).  However, I have no recollection at all about what the
> connection actually was.  It might be possible to pull some of Ken's old
> papers (late 70s/early 80s) and get more information there.
> 
> eric

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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-12 17:20           ` Clem Cole
@ 2019-01-12 18:16             ` Eric Allman
  2019-01-13  1:16               ` Madeline Autumn-Rose
  0 siblings, 1 reply; 22+ messages in thread
From: Eric Allman @ 2019-01-12 18:16 UTC (permalink / raw)
  To: Clem Cole, TUHS main list

> Eric, please fill me in.

I have to admit that my memories are a bit fuzzy, but I'll try to fill
in what I can.

On 2019-01-12 9:20 AM, Clem Cole wrote:
...
> FWIW: Since I had been working networking at both CMU and Tek before I
> came to UCB, one of the first things I did when I arrived in fall '81
> was to install the Gurwitz BBN IP/TCP stack on 4.1 so we could run
> Ethernet between the 3 CAD machines in Cory Hall to replace the use of
> BerkNet over 9600 baud serial links (IIRC Eric Cooper, was involved with
> that hack also).   When I had arrived, few machines at UCB were on LANS
> and the need for ARPAnet style networking >>besides<< email was still
> limited.  The way people connected to systems was their terminal was to
> connect over serial links and we had a giant 'plugboard' that allowed
> you patch your terminal into one of the systems [I wonder if there are
> pictures of these somewhere in the UCB archives - it was quite something].

That it was.  When the INGRES group got our ARPAnet connection (VDH to
LBL, as you mentioned) it was the only long-haul connection to campus
that I know of.  Eric Schmidt had done BerkNET, but that was local mail
and file copy only, and BerkNET mail didn't connect to ARPAnet mail, so
there were "plugboard wars" over who got one of the two RS232
connections we had available for outside users (this was out of a grand
total of 16 connections on a DH-11, each at about $1000/port, iirc).  I
was nominally responsible for the ARPAnet connection, so I had senior
faculty on my case about how they all "needed" dedicated connections to
their office (but of course they didn't want to pay for them).  This was
the original inspiration for delivermail, which later became sendmail.

> We had three 780s in the CAD group in Cory and really did not like the
> plugboard scheme. From my previous experience, I wanted something like
> telnet or supdup, like we had been messing with at CMU and Tek.  Hence
> my push to put the BBN code on the CAD systems and use an ethernet.   
> Eric, please fill me in.   You must have been running the BBN code then
> also, since Ing70 and then IngVax were the ArpaNet connection (via
> a VHDH to the LBL IMP - UCB did not yet have its own IMP).   But I know
> the CAD systems 4.1 networking stuff was done by me.

As I recall IngVax never had any ARPAnet service, and Ing70 was running
the NCP code from San Diego, which could well have originated at BB&N,
but I can't confirm that from memory.  Conversely, Ing70 was never on
any "modern" networking technology such as 3Mbit ethernet (I don't think
there were even NICs at that time).

> Its a little fuzzy now, but memory is that Bob Kriddle had run a Xerox 3
> Meg cable in Cory, from my machine room over to the Ingres machine room
> also; but I've forgotten the details.  BerkNet (i.e. serial links)
> allowed email to flow on campus, but I'm thinking we were trying to make
> that both more efficient and allow telnet/ftp [which might not have
> happened until after the C/30 IMP was installed in Evan later).   [Since
> all ARPAnet email followed through IngVax, Eric's history of dealing
> with the header file format of the month in the old delivermail program
> would force his writing sendmail - said history has been repeated here
> and elsewhere previously].

Yes, modulo it being Ing70, not IngVax.

> But this thread got me thinking a little bit.   I've forgotten actual
> LAN topology we had a UCB now. I know from the CAD hosts, we could talk
> to the other hosts in our lab in Cory for sure, I want to say we could
> talk to a few other hosts in Evans and Cory; as I know Sam would give me
> code usually via some type of network connection, although sneaker-net
> with 9-track tapes used a great deal too.   I want to say the connection
> was over Kriddle's 3M Xerox cable (Eric do you remember what you had in
> IngVax in those days).  I know we also a had real 10Meg cable in floor
> our lab in Cory, plus at least one Xerox board on one of the systems,
> another had a DEC interface in it, and Interlan boards in at least two
> others another.   We must have even had a 3Com board in the third
> system; as I remember hacking both the Interlan and 3Com drivers (I had
> written a 3Com driver at Tek previous for VMS.  The Interlan board was
> new, as was the DEC board; but I've forgotten what we got when).     The
> original CAD 780 ('Coke')  must have had multiple interfaces in it, but
> I really don't remember.

You would think I would remember more of the network situation around
the INGRES project given that we had someone working on distributed
databases (Ken Birman, now at Cornell I think, did something called
COCANET).  However, I have no recollection at all about what the
connection actually was.  It might be possible to pull some of Ken's old
papers (late 70s/early 80s) and get more information there.

eric

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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-12 12:04         ` reed
@ 2019-01-12 17:20           ` Clem Cole
  2019-01-12 18:16             ` Eric Allman
  0 siblings, 1 reply; 22+ messages in thread
From: Clem Cole @ 2019-01-12 17:20 UTC (permalink / raw)
  To: TUHS main list

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

Paul, I can date it a little I suspect, although not as precisely as you
might like.  I arrived at UCB in late August/Early September '81 to be a
grad student.  Sam had arrived earlier that spring to work for wnj in the
CSRG team. I had known Sam before I went to UCB.   [We actually had played
rugby against each other in eastern PA many years before he went off to
Case and me to CMU].  Anyway, when I arrived Sam was one of the people I
already knew and we socialized a lot together in that fall in particular.

We also know the first 'Alpha' kit of 4.1a was not a thing until the next
summer.  Plus, during the winter was the arguments with ARPA steering
committee about the features that needed to be added. The key item is that
vestigial select(2) does not show up until at least 6-9 months after I
arrived and it seems like it was part of 4.1a.   As I said, I have memories
of discussing all of the networking interfaces, CMU Accent, et al with Sam
in particular during that time. So, I would bet Joy did the basic work
winter/spring of 82; but I can not be more precise than that.

FWIW: Since I had been working networking at both CMU and Tek before I came
to UCB, one of the first things I did when I arrived in fall '81 was to
install the Gurwitz BBN IP/TCP stack on 4.1 so we could run Ethernet
between the 3 CAD machines in Cory Hall to replace the use of BerkNet over
9600 baud serial links (IIRC Eric Cooper, was involved with that hack
also).   When I had arrived, few machines at UCB were on LANS and the need
for ARPAnet style networking >>besides<< email was still limited.  The way
people connected to systems was their terminal was to connect over serial
links and we had a giant 'plugboard' that allowed you patch your terminal
into one of the systems [I wonder if there are pictures of these somewhere
in the UCB archives - it was quite something].

We had three 780s in the CAD group in Cory and really did not like the
plugboard scheme. From my previous experience, I wanted something like
telnet or supdup, like we had been messing with at CMU and Tek.  Hence my
push to put the BBN code on the CAD systems and use an ethernet.    Eric,
please fill me in.   You must have been running the BBN code then also,
since Ing70 and then IngVax were the ArpaNet connection (via a VHDH to the
LBL IMP - UCB did not yet have its own IMP).   But I know the CAD systems
4.1 networking stuff was done by me.

Its a little fuzzy now, but memory is that Bob Kriddle had run a Xerox 3
Meg cable in Cory, from my machine room over to the Ingres machine room
also; but I've forgotten the details.  BerkNet (i.e. serial links) allowed
email to flow on campus, but I'm thinking we were trying to make that both
more efficient and allow telnet/ftp [which might not have happened until
after the C/30 IMP was installed in Evan later).   [Since all ARPAnet email
followed through IngVax, Eric's history of dealing with the header file
format of the month in the old delivermail program would force
his writing sendmail - said history has been repeated here and elsewhere
previously].

But this thread got me thinking a little bit.   I've forgotten actual LAN
topology we had a UCB now. I know from the CAD hosts, we could talk to the
other hosts in our lab in Cory for sure, I want to say we could talk to a
few other hosts in Evans and Cory; as I know Sam would give me code usually
via some type of network connection, although sneaker-net with 9-track
tapes used a great deal too.   I want to say the connection was over
Kriddle's 3M Xerox cable (Eric do you remember what you had in IngVax in
those days).  I know we also a had real 10Meg cable in floor our lab in
Cory, plus at least one Xerox board on one of the systems, another had a
DEC interface in it, and Interlan boards in at least two others another.
 We must have even had a 3Com board in the third system; as I remember
hacking both the Interlan and 3Com drivers (I had written a 3Com driver at
Tek previous for VMS.  The Interlan board was new, as was the DEC board;
but I've forgotten what we got when).     The original CAD 780 ('Coke')
must have had multiple interfaces in it, but I really don't remember.

FWIW: I spent a good bit of time with Sam in those days. CSRG was using
750s for most of their development, and the couple of 780's in Evan's had a
lot of non-DEC equipment in them.   But we had the one large undoctored and
max configuration VAX 785 ('Pepsi'), that was fully tricked out with a real
DEC I/O equipment in it†  So when CRSG (*i.e.* Sam) wanted to test things
on a 'pure DEC' system with things like TU78's, real RP07's, RMxx drives;
he would give me something and I would debug it late at night on it.  Once
it was stable, it might become the system we ran.

While I can not date select(2) more precisely.  I can date routed(2) as
being that spring, but after 4.1a's alpha code.   Sam has seen the Xerox
routed system at PARC.   The BBN code was a not friendly to sub-nets and we
had already started to proliferate them between Evans and Cory Hall.   He
decided to create something like the Xerox code for us (as well as the r*
commands). routed was created in a couple of weeks after Sam got the idea
from Xerox and first place it ran was on the 10 Meg LAN in the CAD group.

Hope this helps,
Clem


† That specific system ('Pepsi') had been used as a demo machine for DEC at
Summer Comdex.  It was the famous "forklift'' system and we actually had in
a back room the panel with the forklift holes. It had been donated by Al
Hanover of DEC's CAD team to the UCB CAD group; after Prof. Rich Newton had
convinced >>HP<< to fund the purchasing of an earlier 780 for us [this is
all a different story]. Also, that system had the big 64-bit array
processor I was working on for my thesis too; because it was the only
system we had with enough I/O bandwidth to support it.
ᐧ

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

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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-11 22:18       ` Larry McVoy
@ 2019-01-12 12:04         ` reed
  2019-01-12 17:20           ` Clem Cole
  0 siblings, 1 reply; 22+ messages in thread
From: reed @ 2019-01-12 12:04 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list

On Fri, 11 Jan 2019, Larry McVoy wrote:

> On Fri, Jan 11, 2019 at 04:08:25PM -0600, reed@reedmedia.net wrote:
> > Can someone tell me about SCCS behaviour when renaming/moving or 
> > deleting files?
...

> SCCS didn't know about renames, it was strictly checkin/checkout.
...

> Anyhoo, I digress, that's all BitKeeper, not SCCS.  If you have
> the SCCS history somewhere where I can get it I might be able to
> find the file you want.  Just point me at (I know I have that 
> set somewhere but no idea where they are).

I was surprised that I didn't see the files at the TUHS archives.

I put the SCCS and s. files into
http://reedmedia.net/~reed/tmp/4.1c1-sccs.tar.gz
1.4MB
408 files

I was looking for the early select() code from ~1981. The earliest I 
found was kern_descrip.c from 82/07/15. I think the original source file 
got deleted or the file was renamed and lost its history (and the 
original SCCS s. file was lost).

Thanks

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

* Re: [TUHS] V6 networking & alarm syscall
       [not found] <mailman.1.1547258402.6716.tuhs@minnie.tuhs.org>
@ 2019-01-12 11:13 ` Paul Ruizendaal
  0 siblings, 0 replies; 22+ messages in thread
From: Paul Ruizendaal @ 2019-01-12 11:13 UTC (permalink / raw)
  To: tuhs


> / uses the system sleep call rather than the standard C library
> / sleep (sleep (III)) because there is a critical race in the
> / C library implementation which could result in the process
> / pausing forever. This is a horrible bug in the UNIX process
> / control mechanism.
> 
> Quoted without comment from me!

Intriguing comment. I think your v6+ system probably has a lot of
PWB stuff in there. The libc source for sleep() in stock V6 is:

.globl	_sleep
sleep = 35.

_sleep:
	mov	r5,-(sp)
	mov	sp,r5
	mov	4(r5),r0
	sys	sleep
	mov	(sp)+,r5
	rts	pc

The PWB version uses something alarm/pause based, but apparently
gets it wrong:

.globl	_sleep
alarm = 27.
pause = 29.
rti = 2

_sleep:
	mov	r5,-(sp)
	mov	sp,r5
	sys	signal; 14.; 1f
	mov	4(r5),r0
	sys	alarm
	sys	pause
	clr	r0
	sys	alarm
	mov	(sp)+,r5
	rts	pc

1:
	rti

I think the race occurs when an interrupt arrives between the sys alarm
and the sys pause lines, and the handler calls sleep again.

sleep() in the V7 libc is a much more elaborate C routine.

When I first read the race condition comment, I thought the issue would
be like that of write:

_write:
	mov	r5,-(sp)
	mov	sp,r5
	mov	4(r5),r0
	mov	6(r5),0f
	mov	8(r5),0f+2
	sys	0; 9f
	bec	1f
	jmp	cerror
1:
	mov	(sp)+,r5
	rts	pc
.data
9:
	sys	write; 0:..; ..

This pattern appears in several V6 sys call routines, and would
not be safe when used in a context with signal based multi-
threading.




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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-12  1:58 ` Dave Horsfall
@ 2019-01-12  2:33   ` Warner Losh
  0 siblings, 0 replies; 22+ messages in thread
From: Warner Losh @ 2019-01-12  2:33 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

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

On Fri, Jan 11, 2019 at 6:59 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Fri, 11 Jan 2019, Noel Chiappa wrote:
>
> [ ... ]
>
> >         ioctl (0, FIONREAD, &nch);
> >                        if (nch == 0) {
> >                                tk_yield ();
> >                                continue;
> >                        }
> >                }
> >                if ((c = getchar()) == EOF) {
> >
> > so that ioctl() must look to see if there is any data waiting in the
> > terminal input buffer (I'm too lazy to go see what FIONREAD does, right
> > at the moment).
>
> As I dimly recall (because I'm too sick/lazy to look it up), it returns
> the number of characters in the input queue (at that time) so that you
> won't block (and time out, if you wrote it thus).
>
> It was quite useful, if you didn't like the horrible semantics of
> select(), or, for that matter, SysV poll() (?) which was only slightly
> better.
>
> Of course, FIONREAD wasn't always reliable, because by the time you got to
> using it the keyboard (l)user could have deleted some characters etc, and
> you *could* be left there hanging on a timeout (with signals, which for
> some reason I hate with a passion, as I've posted here before, as they
> are just too brutal).
>

This is why RAW mode was born, but then you're duplicating the kernel
cooking code in your ap :(


> No doubt someone here will tell me that Plan9 did it right :-)  I really
> must run it up some time, before I finally kark it (I'm in my late 60s).
>

No doubt...

Warner

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

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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-12  1:24 Noel Chiappa
@ 2019-01-12  1:58 ` Dave Horsfall
  2019-01-12  2:33   ` Warner Losh
  0 siblings, 1 reply; 22+ messages in thread
From: Dave Horsfall @ 2019-01-12  1:58 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Fri, 11 Jan 2019, Noel Chiappa wrote:

[ ... ]

>         ioctl (0, FIONREAD, &nch);
>                        if (nch == 0) {
>                                tk_yield ();
>                                continue;
>                        }
>                }
>                if ((c = getchar()) == EOF) {
>
> so that ioctl() must look to see if there is any data waiting in the 
> terminal input buffer (I'm too lazy to go see what FIONREAD does, right 
> at the moment).

As I dimly recall (because I'm too sick/lazy to look it up), it returns 
the number of characters in the input queue (at that time) so that you 
won't block (and time out, if you wrote it thus).

It was quite useful, if you didn't like the horrible semantics of 
select(), or, for that matter, SysV poll() (?) which was only slightly 
better.

Of course, FIONREAD wasn't always reliable, because by the time you got to 
using it the keyboard (l)user could have deleted some characters etc, and 
you *could* be left there hanging on a timeout (with signals, which for 
some reason I hate with a passion, as I've posted here before, as they 
are just too brutal).

No doubt someone here will tell me that Plan9 did it right :-)  I really 
must run it up some time, before I finally kark it (I'm in my late 60s).

-- Dave

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

* Re: [TUHS] V6 networking & alarm syscall
@ 2019-01-12  1:24 Noel Chiappa
  2019-01-12  1:58 ` Dave Horsfall
  0 siblings, 1 reply; 22+ messages in thread
From: Noel Chiappa @ 2019-01-12  1:24 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Paul Ruizendaal

    > It would not seem terribly complex to add non-blocking i/o capability to
    > V6. ...  Adding a 'capacity' field to the sgtty interface would not
    > have been a big leap either. ...
    > Maybe in the 1975-1980 time frame this was not felt to be 'how Unix does
    > it'?

This point interested me, so I went and had a look at how the MIT V6+/PWB
TCP/IP did it. I looked at user TELNET, which should be pretty simple (server
would probably be more complicated, due to PTY stuff).

It's totally different - although that's in part because in the MIT system,
TCP is in the user process, along with the application. In the user process,
there's a common non-premptive 'tasking' package which both the TCP and TELNET
code use. When there are no tasks ready to run, the process uses the sleep()
system call to wait for a fixed, limited quantum (interrupts, i.e. signals,
will usually wake it before the quantum runs out); note this comment:

 / uses the system sleep call rather than the standard C library
 / sleep (sleep (III)) because there is a critical race in the
 / C library implementation which could result in the process
 / pausing forever. This is a horrible bug in the UNIX process
 / control mechanism.

Quoted without comment from me!

There are 3 TCP tasks - send, receive and timer. The process receives an
'asynchronous I/O complete' signal when a packet arrives, and that wakes up
the process, and then one of the tasks therein, to do packet processing
(incoming data, acks, etc).

There appears to be a single TELNET task, which reads from the user's
keyboard, and sends data to the network. (It looks like processing of incoming
data is handled in the context of one of the TCP tasks.) Its main loop starts
with this:

         ioctl (0, FIONREAD, &nch);
                        if (nch == 0) {
                                tk_yield ();
                                continue;
                        }
                }
                if ((c = getchar()) == EOF) {

so that ioctl() must look to see if there is any data waiting in the terminal
input buffer (I'm too lazy to go see what FIONREAD does, right at the moment).

      Noel

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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-11 22:47       ` Clem Cole
  2019-01-11 22:55         ` Eric Allman
@ 2019-01-11 23:32         ` Warner Losh
  1 sibling, 0 replies; 22+ messages in thread
From: Warner Losh @ 2019-01-11 23:32 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

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

On Fri, Jan 11, 2019 at 3:48 PM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Fri, Jan 11, 2019 at 5:09 PM <reed@reedmedia.net> wrote:
>
>>
>> The select system call was added in 81/02/07 with no comment. Commit
>> history shows in 81/10/17: "cleanup (mpx removal, old tty removal,
>> beginnings of select)" and in 81/10/11 "first boot with select()" which
>> includes lots of changes like replace lots of tty code and use
>> selwakeup().
>
>
> Actually, that is a nice memory jog.   Chesson wrote mpx(2) for DataKit
> for UNIX/TS.   IIRC: It was not originally part of v7, but he sent copies
> of out to a number of folks.    Somwhere I might even have the email when
> he sent it to me at CMU in the late 1970s.   The point is that it was in
> the wild as it were at a lot of places; certainly at UCB by 4.1.    Sam and
> Joy had seen  and messed with mpx(2) before select(2) was concieved.
>
> To Paul's question - mpx(2) was done for networking.
>

How is that different than the pk driver that was in v7?

Warner

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

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

* [TUHS] V6 networking & alarm syscall
@ 2019-01-11 23:27 Paul Ruizendaal
  0 siblings, 0 replies; 22+ messages in thread
From: Paul Ruizendaal @ 2019-01-11 23:27 UTC (permalink / raw)
  To: tuhs@minnie.tuhs.org list

Clem, Ron,

Thanks for the explanations! Some comments below.

>> 1. First of all: I understand that early Unix version numbers and dates
>> mostly refer to the manual editions, and that core users had more
>> frequent snapshots of a constantly evolving code base.
> 
> Eh?  They primarily refer to the distributions (Research V6, V7, PWB, the
> various BSD tapes).
> I'm not sure what "core users" are referring to.   Most of us had many
> versions as we hacked and merged the stock releasesx.

I was too brief. I was referring just to the pre-V7 versions, and I had the implicit assumption that alarm() originated at the labs. My understanding was that the labels 5th, 6th and 7th edition had little meaning inside the labs, as there just was a continuously developing code base. Maybe this is a mis-understanding.

> "alarm was introduced as part of Unix/TS" "PWB [..] had both sleep() and alarm() as system calls"

Thanks for those pointers! I'm not sure I fully grasp the lineage of Unix/TS and PWB, but the TUHS wiki has a page about it: https://wiki.tuhs.org/doku.php?id=misc:snippets:mert1

From that, and from the TUHS Unix Tree web page I get that PWB1.0 from mid 1977 was probably the root source of alarm() for people outside AT&T. As PWB apparently got started much before that, it is possible that alarm() goes back much further as well.

> A bigger networking issue was select() (or the like). It used to be an
> interesting kludge of running two processes inorder to do simoultaneous
> read/write before that.

Yes: the NCP Unix team (Grossman/Holmgren/Bunch) also mentioned that as the big issue/annoyance that they ran into in 1975.

As discussed in this list before, 3 years elapsed before Jack Haverty came up with await() for V6. I was told that there was a lot of discussion in the 4.1x/4.2 BSD steering group in 1981/2 whether this functionality should be stateful (like await) or stateless (like select). Looking at the implementations for both, I can see why stateless carried the day.

> Right and select(2) was created by Sam and wnj during the 4.2 development.  I've forgotten which sub-version (it was in 4.1c, but it might have been in b or a before that).  There was a lot of arguing at the time about it's need;  the multiple process solution was considered more 'Unix-like.'

That is an interesting point, and it got me wondering about another related feature that could have been in Unix in the 1975-1980 time frame, being both useful and practical even on a 11/40 class machine, but for some reason wasn't:

It would not seem terribly complex to add non-blocking i/o capability to V6. It could have been implemented as a TTY flag and it is not a big conceptual leap from EINTR to EAGAIN. Adding a 'capacity' field to the sgtty interface would not have been a big leap either. This would have allowed user processes to scan a number of tty lines e.g. once a second in a loop and do processing as needed. In NCP Unix this would not have been hard to extend to network pipes.

The NCP Unix / Arpanet crowd certainly had a need for it, it would have been very useful for Spider/Datakit connections and probably for uucp as well. And from there it is not a million miles to replace the timed user loop with something like select(). Yet non-blocking I/O and select() only appear in 1982.

Maybe in the 1975-1980 time frame this was not felt to be 'how Unix does it'?



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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-11 22:47       ` Clem Cole
@ 2019-01-11 22:55         ` Eric Allman
  2019-01-11 23:32         ` Warner Losh
  1 sibling, 0 replies; 22+ messages in thread
From: Eric Allman @ 2019-01-11 22:55 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

On 2019-01-11 2:47 PM, Clem Cole wrote:
> To Paul's question - mpx(2) was done for networking.

Trivia point: I used mpx(2) for the very first implementation of syslog.

eric

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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-11 22:08     ` reed
  2019-01-11 22:18       ` Larry McVoy
@ 2019-01-11 22:47       ` Clem Cole
  2019-01-11 22:55         ` Eric Allman
  2019-01-11 23:32         ` Warner Losh
  1 sibling, 2 replies; 22+ messages in thread
From: Clem Cole @ 2019-01-11 22:47 UTC (permalink / raw)
  To: Jeremy C. Reed; +Cc: TUHS main list

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

On Fri, Jan 11, 2019 at 5:09 PM <reed@reedmedia.net> wrote:

>
> The select system call was added in 81/02/07 with no comment. Commit
> history shows in 81/10/17: "cleanup (mpx removal, old tty removal,
> beginnings of select)" and in 81/10/11 "first boot with select()" which
> includes lots of changes like replace lots of tty code and use
> selwakeup().


Actually, that is a nice memory jog.   Chesson wrote mpx(2) for DataKit for
UNIX/TS.   IIRC: It was not originally part of v7, but he sent copies of
out to a number of folks.    Somwhere I might even have the email when he
sent it to me at CMU in the late 1970s.   The point is that it was in the
wild as it were at a lot of places; certainly at UCB by 4.1.    Sam and Joy
had seen  and messed with mpx(2) before select(2) was concieved.

To Paul's question - mpx(2) was done for networking.

Clem
ᐧ

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

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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-11 22:08     ` reed
@ 2019-01-11 22:18       ` Larry McVoy
  2019-01-12 12:04         ` reed
  2019-01-11 22:47       ` Clem Cole
  1 sibling, 1 reply; 22+ messages in thread
From: Larry McVoy @ 2019-01-11 22:18 UTC (permalink / raw)
  To: reed; +Cc: TUHS main list

On Fri, Jan 11, 2019 at 04:08:25PM -0600, reed@reedmedia.net wrote:
> Can someone tell me about SCCS behaviour when renaming/moving or 
> deleting files? In particular, I think the select() code prior to 
> 82/07/15 had different source filenames that no longer exist and the 
> SCCS history was lost.  Anyone else have ideas about this?  I have 
> noticed this with other SCCS spelunking where code was removed and then 
> corresponding "s" files were missing -- but maybe that is just the way 
> the systems that our current snapshots (McKusick discs) of this history 
> were made from. Maybe sccs didn't checkout the history of deleted files 
> by default (that is my guess).

Ah, SCCS is my jam (I rewrote it from scratch as part of BitKeeper).

SCCS didn't know about renames, it was strictly checkin/checkout.
BitKeeper added the concept of "inode" to SCCS though it was not
an integer like an inode in Unix, it was what we called a "key"
and it looked like 

	user@host|pathname|time_t|SCCS_chksum|64bits_of_dev_random

There was a key for each delta and the name of the file was an 
attribute of the delta just as the contents were.  So internally
we worked in keys but externally you used file names and it was
trivial to see where the file had lived.

Anyhoo, I digress, that's all BitKeeper, not SCCS.  If you have
the SCCS history somewhere where I can get it I might be able to
find the file you want.  Just point me at (I know I have that 
set somewhere but no idea where they are).
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-11 18:45   ` Clem Cole
  2019-01-11 19:06     ` David
@ 2019-01-11 22:08     ` reed
  2019-01-11 22:18       ` Larry McVoy
  2019-01-11 22:47       ` Clem Cole
  1 sibling, 2 replies; 22+ messages in thread
From: reed @ 2019-01-11 22:08 UTC (permalink / raw)
  To: TUHS main list

On Fri, 11 Jan 2019, Clem Cole wrote:

> Right and select(2) was created by Sam and wnj during the 4.2 development.?
> I've forgotten which sub-version (it was in 4.1c, but it might have been in
> b or a before that).? There was a lot of arguing at the time about it's need;?
> the multiple process solution was considered more 'Unix-like.'
...

I search through the SCCS code in 4.1c. There is a reference to it by 
name for 4.1a in syscalls.c (82/11/13) to answer your comment.

"#38 -- 4.1a select",   /*  38 = nosys */

The select system call was added in 81/02/07 with no comment. Commit 
history shows in 81/10/17: "cleanup (mpx removal, old tty removal, 
beginnings of select)" and in 81/10/11 "first boot with select()" which 
includes lots of changes like replace lots of tty code and use 
selwakeup().

But I don't see any of the select code itself until a new file 
kern_descrip.c was introduced in 82/07/15. Soon after the #38 select 
became obsoleted oselect and a new syscall number #93 was assigned.
(In 4.2 the select code was in sys_generic.c.)

Can someone tell me about SCCS behaviour when renaming/moving or 
deleting files? In particular, I think the select() code prior to 
82/07/15 had different source filenames that no longer exist and the 
SCCS history was lost.  Anyone else have ideas about this?  I have 
noticed this with other SCCS spelunking where code was removed and then 
corresponding "s" files were missing -- but maybe that is just the way 
the systems that our current snapshots (McKusick discs) of this history 
were made from. Maybe sccs didn't checkout the history of deleted files 
by default (that is my guess).

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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-11 18:45   ` Clem Cole
@ 2019-01-11 19:06     ` David
  2019-01-11 22:08     ` reed
  1 sibling, 0 replies; 22+ messages in thread
From: David @ 2019-01-11 19:06 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

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


> On Jan 11, 2019, at 10:45 AM, Clem Cole <clemc@ccc.com> wrote:
> FWIW: a few years later, System V (I think SRV3, but I've forgotten) introduced poll(2) as a reaction to BSD's select(2).   [IMO: That was NIH if I ever saw it - similar but different because they could].
> 
> Clem
> ᐧ

I remember having to support software than was on both SVR4 and BSD and writing an API that would mask the difference between poll and select. I’ve seen it done many times sense.

	David


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

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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-11 15:33 ` ron
@ 2019-01-11 18:45   ` Clem Cole
  2019-01-11 19:06     ` David
  2019-01-11 22:08     ` reed
  0 siblings, 2 replies; 22+ messages in thread
From: Clem Cole @ 2019-01-11 18:45 UTC (permalink / raw)
  To: Ronald Natalie; +Cc: TUHS main list, Paul Ruizendaal

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

On Fri, Jan 11, 2019 at 10:34 AM <ron@ronnatalie.com> wrote:

> A bigger networking issue was select() (or the like).    It used to be an
> interesting kludge of running two processes inorder to do simoultaneous
> read/write before that.
>
Right and select(2) was created by Sam and wnj during the 4.2 development.
I've forgotten which sub-version (it was in 4.1c, but it might have been in
b or a before that).  There was a lot of arguing at the time about it's
need;  the multiple process solution was considered more 'Unix-like.'   I
remember one time have a few beers in my apartment with Sam while watching
a football game and arguing about its usefulness.  Adding select(2)  was an
example of where CSRG was adding things to UNIX for the DARPA community.
 IIRC: previous PDP-10 system had something like it and of course VMS had
qio() which did not block; some of the users at an advisors meeting had
wanted some alaong.    I also remember after it ws prototyped, some people
complaining that with select(2) people would start to right code that
looped and waste cycles.  BTW: sure enough, about a year or two later,
X-Windows appears with its keyboard/mouse loop.  The argument on a
workstation (personal computer) was it did not matter.  The argument on a
vax or other typeshared machine, was that the CPU was being wasted and any
type polling loop in users space was a bad idea.

FWIW: a few years later, System V (I think SRV3, but I've forgotten) introduced
poll(2) as a reaction to BSD's select(2).   [IMO: That was NIH if I ever
saw it - similar but different because they could].

Clem
ᐧ

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

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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-10 23:12 Paul Ruizendaal
  2019-01-11  0:17 ` Clem cole
@ 2019-01-11 15:33 ` ron
  2019-01-11 18:45   ` Clem Cole
  1 sibling, 1 reply; 22+ messages in thread
From: ron @ 2019-01-11 15:33 UTC (permalink / raw)
  To: 'Paul Ruizendaal', tuhs

> 
> 1. First of all: I understand that early Unix version numbers and dates
mostly
> refer to the manual editions, and that core users had more frequent
> snapshots of a constantly evolving code base.

Eh?  They primarily refer to the distributions (Research V6, V7, PWB, the
various BSD tapes).
I'm not sure what "core users" are referring to.   Most of us had many
versions as we hacked and merged the stock releasesx.

As Clem mentions, V7 had alarm (but simulated sleep in user mode).  PWB
predated that slightly and had both sleep() and alarm() as system calls.
This propagated through to System III and V.
I suspect this all is the result of the philosophy of the guys responsible
for those separate kernel developments rather than an evolution of one or
the other.

As he mentions, I'm fairly sure this has nothing to do with networking
directly.   Just too handy not to have.

A bigger networking issue was select() (or the like).    It used to be an
interesting kludge of running two processes inorder to do simoultaneous
read/write before that.





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

* Re: [TUHS] V6 networking & alarm syscall
  2019-01-10 23:12 Paul Ruizendaal
@ 2019-01-11  0:17 ` Clem cole
  2019-01-11 15:33 ` ron
  1 sibling, 0 replies; 22+ messages in thread
From: Clem cole @ 2019-01-11  0:17 UTC (permalink / raw)
  To: Paul Ruizendaal; +Cc: tuhs@minnie.tuhs.org list

Paul.  alarm was introduced as part of Unix/TS would become most of kernel for the V7 system


As for networking driving it I can not say. But the need for alarm to be broken from sleep was there for many other types of programs particularly if there was an interactive component or you needed to deal with hw at the user level.  

Look at the ‘expect’ code in uucico (which would later begat the whole expect tool from NIST).   Alarm was just easier to do that with than sleep. 



Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Jan 10, 2019, at 6:12 PM, Paul Ruizendaal <pnr@planet.nl> wrote:
> 
> 
> I'm still happily experimenting with my combination of a V6 kernel with the 1981 tcp/ip stack from BBN, for example figuring out how one would write something like 'ping' using that API. That brought me to pondering the origins of the 'alarm()' sys call and how some things were done on the Spider network.
> 
> These are my observations:
> 
> 1. First of all: I understand that early Unix version numbers and dates mostly refer to the manual editions, and that core users had more frequent snapshots of a constantly evolving code base.
> 
> 2. If I read the TUHS archive correctly, alarm() apparently did not exist in the original V6 edition of mid-1975. On the same basis, it was definitely there by the time of the V7 edition of early '79 (with sleep() removed) - so alarm() would seem to have appeared somewhere in the '75-'78 time frame.
> 
> 3. The network enhanced NCP Unix versions in the TUHS archive have alarm() appear next to sleep(). Although the surviving tapes date from '79, it would seem to suggest that alarm() may have originated in the earlier part of the '75-'78 time frame.
> 
> 4. The Spider network file store program 'nfs' (source here: http://chiselapp.com/user/pnr/repository/Spider/dir?mtime=0&type=flat&udc=1&ci=tip) uses idioms like the below to avoid getting hung on a dead server/network:
> 
>    signal(14,timeout); alarm(30);
>    if((read(fn,rply,100)) < 0) trouble();
>    alarm(0);
> 
> The 'nfs' program certainly was available in the 5th edition, maybe even in the 4th edition (the surviving 4th edition source code includes a Spider device driver). However, the surviving source for 'nfs' is from 1979 as well, so it may include later additions to the original design.
> 
> 5. Replacing sleep() with alarm() and a user space library routine seems to have happened only some time after alarm() appeared, so it would seem that this was an optimization that alarm() enabled, and not its raison d'être.
> 
> So here are some questions that the old hands may be able to shed some light on:
> 
> - When/where did alarm() appear? Was network programming driving its inception?
> 
> - Did Spider programs use a precursor to alarm() before that? (similar to V5 including 'snstat' in its libc - a precursor to ioctl).
> 
> Paul
> 

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

* [TUHS] V6 networking & alarm syscall
@ 2019-01-10 23:12 Paul Ruizendaal
  2019-01-11  0:17 ` Clem cole
  2019-01-11 15:33 ` ron
  0 siblings, 2 replies; 22+ messages in thread
From: Paul Ruizendaal @ 2019-01-10 23:12 UTC (permalink / raw)
  To: tuhs@minnie.tuhs.org list


I'm still happily experimenting with my combination of a V6 kernel with the 1981 tcp/ip stack from BBN, for example figuring out how one would write something like 'ping' using that API. That brought me to pondering the origins of the 'alarm()' sys call and how some things were done on the Spider network.

These are my observations:

1. First of all: I understand that early Unix version numbers and dates mostly refer to the manual editions, and that core users had more frequent snapshots of a constantly evolving code base.

2. If I read the TUHS archive correctly, alarm() apparently did not exist in the original V6 edition of mid-1975. On the same basis, it was definitely there by the time of the V7 edition of early '79 (with sleep() removed) - so alarm() would seem to have appeared somewhere in the '75-'78 time frame.

3. The network enhanced NCP Unix versions in the TUHS archive have alarm() appear next to sleep(). Although the surviving tapes date from '79, it would seem to suggest that alarm() may have originated in the earlier part of the '75-'78 time frame.

4. The Spider network file store program 'nfs' (source here: http://chiselapp.com/user/pnr/repository/Spider/dir?mtime=0&type=flat&udc=1&ci=tip) uses idioms like the below to avoid getting hung on a dead server/network:

	signal(14,timeout); alarm(30);
	if((read(fn,rply,100)) < 0) trouble();
	alarm(0);

The 'nfs' program certainly was available in the 5th edition, maybe even in the 4th edition (the surviving 4th edition source code includes a Spider device driver). However, the surviving source for 'nfs' is from 1979 as well, so it may include later additions to the original design.

5. Replacing sleep() with alarm() and a user space library routine seems to have happened only some time after alarm() appeared, so it would seem that this was an optimization that alarm() enabled, and not its raison d'être.

So here are some questions that the old hands may be able to shed some light on:

- When/where did alarm() appear? Was network programming driving its inception?

- Did Spider programs use a precursor to alarm() before that? (similar to V5 including 'snstat' in its libc - a precursor to ioctl).

Paul


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

end of thread, other threads:[~2019-01-13 15:39 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-12  4:14 [TUHS] V6 networking & alarm syscall Noel Chiappa
  -- strict thread matches above, loose matches on Subject: below --
2019-01-13 10:52 Paul Ruizendaal
2019-01-13 15:39 ` Warner Losh
     [not found] <mailman.1.1547258402.6716.tuhs@minnie.tuhs.org>
2019-01-12 11:13 ` Paul Ruizendaal
2019-01-12  1:24 Noel Chiappa
2019-01-12  1:58 ` Dave Horsfall
2019-01-12  2:33   ` Warner Losh
2019-01-11 23:27 Paul Ruizendaal
2019-01-10 23:12 Paul Ruizendaal
2019-01-11  0:17 ` Clem cole
2019-01-11 15:33 ` ron
2019-01-11 18:45   ` Clem Cole
2019-01-11 19:06     ` David
2019-01-11 22:08     ` reed
2019-01-11 22:18       ` Larry McVoy
2019-01-12 12:04         ` reed
2019-01-12 17:20           ` Clem Cole
2019-01-12 18:16             ` Eric Allman
2019-01-13  1:16               ` Madeline Autumn-Rose
2019-01-11 22:47       ` Clem Cole
2019-01-11 22:55         ` Eric Allman
2019-01-11 23:32         ` Warner Losh

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).