TUHS

tuhs@tuhs.org

49 participants
6504 discussions

by Doug McIlroy

Ptrace was short-lived at Research, appearing in 6th through 8th editions. /proc was introduced in the 8th. Norman axed it in the 9th. Norman wrote: nobody wanted to update adb and sdb, which were big messes inside. So I did ... 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. doug

5 years, 11 months

Re: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane")

by Kirk McKusick

> From: ron minnich <rminnich(a)gmail.com> > To: TUHS main list <tuhs(a)minnie.tuhs.org> > Subject: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and > arcane") > Message-ID: > <CAP6exYJshbA5HxOJ_iM21Cs0Y4vGfLuFigXxh4WTeqbZreY8UA(a)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

5 years, 11 months

4.1c bsd ptrace man entry ("ptrace is unique and arcane")

by ron minnich

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

5 years, 11 months

OT: Need help getting old 9 track tapes read

by arnold＠skeeve.com

Hi All. Scott Lee, who worked with me on the Georgia Tech Software Tools Subystem for Pr1me Computers, recently unearthed two tapes with some version of that software. These may be the only copies extant anywhere. He says: | I was cleaning out the basement of my house. They're 35 years old, but | they've never been left in the heat or anything. I opened one of them | up and checked the tape and it's not self-sticky or anything. The odds | that they're readable is slim, because old 9-track bits tended to bleed | through each other. You were supposed to spin through the tape every | couple of years to make them last longer. That's obviously not happened. There was discussion here a while back about services that will recover such tapes and so on. But I didn't save any of that information. If you have information, PLEASE send it to me so that I can relay it to Scott. Dennis Boone & Bill Gunshannon (are you on this list?) - I may ask you to contribute $$ towards this once I know more. Thanks! Arnold

5 years, 11 months

Re: [TUHS] CMU Mach sources?

by jnc＠mercury.lcs.mit.edu

> From: Andrew Warkentin > Mach and the other kernels influenced by it basically destroyed the > reputation of microkernels ... a simple read() of a disk file, which is > a single kernel call on a monolithic kernel and usually two context > switches on QNX, takes at least 8 context switches - client->VFS->disk > FS->partition driver->disk driver and back again). Hammer-nail syndrome. When the only tool you have for creating separate subsystems is processes, you wind up with a lot of processes. Who'd a thunk it. A system with a segmented memory which allows subroutine calls from one subsystem to another will have a lot less overhead. It does take hardware support to be really efficient, though. The x86 processors had that support, until Intel dropped it from the latest ones because nobody used it. Excuse me while I go bang my head on a very hard wall until the pain stops. Noel

5 years, 11 months

Any oldtimers remember anything about the KS11 on the -11/20?

by jnc＠mercury.lcs.mit.edu

This is an appeal to the few really-old-timers (i.e. who used the PDP-11/20 version of Unix) on the list to see if they remember _anything_ of the KS11 memory mapping unit used on that machine. Next to nothing is known of the KS11. Dennis' page "Odd Comments and Strange Doings in Unix": https://www.bell-labs.com/usr/dmr/www/odd.html has a story involving it (at the end), and that is all I've ever been able to find out about it. I don't expect documentation, but I am hoping someone will remember _basically_ what it did. My original guess as to its functionality, from that page, was that it's not part of the CPU, but a UNIBUS device, placed between the UNIBUS leaving the CPU, and the rest of the the bus, which perhaps mapped addresses around (and definitely limited user access to I/O page addresses). It might also have mapped part of the UNIBUS space which the -11/20 CPU _can_ see (i.e. in the 0-56KB range) up to UNIBUS higher addresses, where 'extra' memory is configured - but that's just a guess; but it is an example of the kind of info I'd like to find out about it - just the briefest of high-level descriptions would be an improvement on what little we have now! On re-reading that page, I see it apparently supported some sort of user/kernel mode distinction, which might have require a tie-in to the CPU. (But not necessarily; if there was a flop in the KS11 which stored the 'CPU mode' bit, it might be automatically cleared on all interrupts. Not sure how it would have handled traps, though.) Even extremely dim memories will be an improvement on the blank canvas we have now! Noel

5 years, 11 months

Re: [TUHS] Any oldtimers remember anything about the KS11 on the 11/20?

by jnc＠mercury.lcs.mit.edu

> From: Rudi Blom > Probably already known, but to be sure Interesting options: MX11 - > Memory Extension Option: this enabled the usage of 128 KW memory (18-bit > addressing range) Actually, I didn't know of that; something else to track down. Wrong list for that, though. Noel

5 years, 11 months

Any oldtimers remember anything about the KS11 on the 11/20?

by Rudi Blom

Probably already known, but to be sure Interesting options: MX11 - Memory Extension Option: this enabled the usage of 128 KW memory (18-bit addressing range); KS11: this option provided hardware memory protection, which the plain /20 lacked. Both options were developed by the Digital CSS (Computer Special Systems). http://hampage.hu/pdp-11/1120.html PS the page listed below has a very nice picture of the 'two fathers of UNIX" working on a PDP-11/20 http://hampage.hu/unix/unix1.html

5 years, 11 months

Re: [TUHS] UNIX 50th at USENIX ATC

by Norman Wilson

Kevin Bowling: The conference looks supremely uninteresting outside one WAFL talk to me. ==== That is, of course, a matter of opinion. Just from skimming titles I see about two dozen talks of at least some interest to me in the ATC program. And that's just ATC; I'm planning to attend the Hot* workshops on Monday and Tuesday as well. Of course I won't attend every one of those talks--some coincide in time, some I'll miss because I get stuck in the hallway track. And some will prove less interesting in practice, though others that don't seem all that interesting in the program will likely prove much better in person. I've been attending USENIX ATC for decades, and although some conferences have been meatier than others, I've never ended up feeling the trip was a waste of time. Perhaps us old farts just aren't as discriminating as you youngsters. That said, I think Kevin's question Is there a way to participate [on the UNIX50 event] without attending Usenix ATC? is a good one. Norman Wilson Toronto ON

5 years, 11 months

RIP Bud Lawson

by Doug McIlroy

Bud Lawson, long an expat living in Sweden, died yesterday. Not a Unix person, he was, however, the originator of a characteristic Unix programmer's idiom. Using an idea adapted from Ken Knowlton, Bud invented the pointer- chasing arrow operator that Dennis Ritchie adopted for C. I played matchmaker. When Bud first proposed the "based storage" (pointer) facility for PL/I, he used the well-established field(pointer) notation. I introduced him to the pointer-chasing notation Knowlton devised for L6. Knowlton, however, had no operator because he had only single-letter identifiers. What we now write as a->b->c, Knowlton wrote as abc. Appreciating the absence of parentheses, Bud came up with the wonderfully intuitive pointer->field notation. Doug

5 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS