TUHS

tuhs@tuhs.org

26 participants
6416 discussions

Re: [TUHS] Paper discussing Unix boot process?

by Pat Barron

The paper I am thinking of (gee, I wish I could remember any other details about it...) was *very* detailed and specific, and was hardware-specific to either the PDP-11 or VAX. It would not at all be applicable to Linux or any kind of modern OS. I am wondering if it is something in the Leffler et al book, I'll have to go back and review that. I'll have to find my copy of it first... --Pat.

5 years, 6 months

The Great NBN Out(r)age

by Dave Horsfall

A few bods have asked to see this, so... Actually, "extracted" would be better description than "redacted", but it's too late now; I could rename it and put in a CGI-redirect, but I'm too busy at the moment. ----- A redacted copy of my complaint to T$. www.horsfall.org/Telstra-comp-redact.rtf (yes, RTF; it was written on a Mac). Utterly inexcusable... Please share etc :-) -- Dave

5 years, 6 months

4.1c bsd ptrace man entry

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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 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