TUHS January 2018

tuhs@tuhs.org

43 participants
40 discussions

by norman＠nose.cita.utoronto.ca

I've assembled some notes from old manuals and other sources on the formats used for on-disk file systems through the Seventh Edition: http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html Additional notes, comments on style, and whatnot are welcome. (It may be sensible to send anything in the last two categories directly to me, rather than to the whole list.)

2 years, 7 months

Dynamics between BSD and Linux

by Kevin Bowling

Hi, Interested in some perspective here since the list has influential Linux people like Ted Tso. Linux has been described as influenced by Minix and System V. The Minix connection is well discussed. The SysV connection something something Linus had access to a spec manual. But I’d guess reality would be more gradual — new contributors that liked CSRG BSD would have mostly gravitated to the continuations in 386/BSDi/Net/Free that were concurrent to early and formative Linux development.. so there’d be an implicit vacuum of BSD people for Linux development. What I am curious about is the continuing ignorance of BSD ideas. Linux isn’t exactly insular; a lot of critical people and components came much later on from other SysV flavors (lvm, jfs, xfs, RCU) The kinds of BSD things I am talking about are ufs, kqueue, jails, pf, Capsicum. Linux has grown alternatives, but with sometimes willful ignorance of other technology. It seems clear epoll was not a good design from the start. Despite jails not being taken to the logical conclusion of modern containers like zones, the architecture is fundamentally closer aligned to how people want to securely use containers versus namespaces and cgroups. And Google ported Capscicum to Linux but it’s basically been ignored in lieu of nebulous concepts like seccomp. And then there seems to be outright hostility toward other platforms from the postmodern generation with things like systemd. This seems strange to me as BSD people are generally open to other /ideas/, we have to be careful with Linux code due to license incompatibility, but the converse is does not seem true either in interest in other ideas or license hampering code flow. The history of UNIX is spectacularly successful because different groups got together at the table and agreeed on the ideas. Is there room for that in the modern era where Linux is the monopoly OS? The Austin Group is still a thing but it’s not clear people in any of the Freenix communities really care about evolving the standards. I get that, but not so much completely burrying ones head in the sand to what other OSes are doing. Is there any future for UNIX as an “open system” in this climate or are people going to go there separate ways? Regards, Kevin

6 years, 10 months

Happy birthday, John von Neumann!

by Dave Horsfall

We gained John von Neumann on this day in 1903, and if you haven't heard of him then you are barely human... As computer science goes, he's right up there with Alan Turing. There is speculation that he knew of Babbage's work; see https://cstheory.stackexchange.com/questions/10828/the-relation-between-bab… . -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

6 years, 10 months

Calgary buffer modifications

by Paul Ruizendaal

For a while I had been wondering about the origins of a modification to the V6 kernel that places the kernel buffers in a separately mapped area, freeing up space for other things. It is used in some of the early networking code, i.e. both the UoI code and the V6 BBN code (as available on the TUHS Unix Tree). I came across the following reference in https://www.osti.gov/scitech/servlets/purl/12130675: “One widely distributed (though undocumented) solution to this hardware limit on the model 40 was a version of Unix by Robert Sidebotham, Faculty of Environmental Design, University of Calgary. His solution was to move the I/O buffers out of kernel space.” This would explain the modifications being bracketed with "#ifdef UCBUFMOD”. Some questions for the old hands: - Was this patch indeed widely known / distributed? - Widely distributed is not the same as widely used: was it?

6 years, 10 months

Happy birthday, Douglas Engelbart!

by Dave Horsfall

Born on this day in 1925, he was a pioneer in human/computer interaction, and invented the mouse; it wasn't exactly ergonomic, being just a square box with a button. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

6 years, 10 months

V6 UNIX main() oddness

by jnc＠mercury.lcs.mit.edu

So, while bringing up V6 on a hardware PDP-11/23 with an RK11 emulator using an SD card for storage which Dave Bridgham and I are doing, I found this piece of code in main() on V6 Unix: rootdir = iget(rootdev, ROOTINO); rootdir->i_flag =& ~ILOCK; u.u_cdir = iget(rootdev, ROOTINO); u.u_cdir->i_flag =& ~ILOCK; I don't get why two separate calls to iget(), with the same arguments; why not replace the second pair of lines with: u.u_cdir = rootdir; rootdir->i_count++; What am I missing? Noel

6 years, 10 months

LSX swapping

by Paul Ruizendaal

>>> LSX has a maximum of three processes that are swapped in and out in a >>> stack-like fashion. Only one process is ever in core. > > I'm having a hard time working out how this works. If process A is swapped > out, and then B, B has to be swapped in before A can be? But only one process > is ever in core at a time? To get A in, B has to be moved out? But then B > would be the last one out, and would have to come in before A? > > Anyway, I don't understand why the OS could/would care which order processes > we swapped in - unless it's something like the 'onion skin' memory allocation > algorithm of CTSS (which also had only a single process resident at a time, > IIRC), where, when a small process had to be swapped in, and a large one was > already in, it only swapped out enough of the large one to make room for the > small one. The process could recurse, hence the name. The LSI-11 had 40KB of core. The lower 16KB held the LSX kernel, the upper 24K was for the active process. LSX has 3 process slots and 2 swap slots (on floppy!). Optionally, LSX could be built with an additional background process ("BGOPTION"), but this does not work very well. Process numbers and swap slots have a 1:1 relationship. There is a global variable, cpid, with the process number of the current process, initially zero. Upon boot, LSX will load a shell as process 0. (There is no swapper process and no init in LSX). The original LSI-11 kernel code is here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX/sys I can refer to source lines in the repository for my TI990 port of it: https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b6ec9496e23efe8c When a process forks, it writes the current core image out to the corresponding swap slot (this swaps out the parent) and the core image is repurposed as the new process (i.e. cpid is incremented and the proc table filled in): https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/3617ec3245c40a69?l… The child now runs and the parent remains suspended until the child completes. Yes, this implies no pipes. The shell is modified to emulate pipes with files. When the child completes, it stores its u area / exit code in its swap slot (as it is running, the swap slot must be empty. Process 3 has a small swap slot just for this). Next LSX decreases cpid and the parent process is reloaded from its swap slot: https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b9c07dfc5add9fc5?l… The actual swapping happens here: https://1587660.websites.xs4all.nl/cgi-bin/9995/artifact/b6ec9496e23efe8c?l… The original PDP11 source has code to compress the empty space between _end and the stack pointer, which I did not get to work properly. LSX works well enough to run the standard V6 binaries unmodified. Some need to be tweaked (e.g. table space in cpp) and the shell needed the pipe change. It can run the V6 c compiler, but not with a wild card argument: that requires 4 stacked processes (sh, glob, cc and cpp/c0/..) and LSX allows only 3. Hope the above makes it a bit more clear.

6 years, 10 months

RIP Marvin Minsky

by Dave Horsfall

We lost AI pioneer Marvin Minsky on this day in 2016 from a cerebral haemorrhage, aged 88. Amongst other things, along with John McCarthy he co-founded the MIT AI Lab, co-invented the Logo "turtle", was mentioned in Arthur C. Clarke's novel "2001: A Space Odyssey", and built the first randomly wired neural network learning machine, SNARC, in 1951. He is now thought to be cryogenically preserved as "Patient 144" at Alcor (he started cooling on 27/1/2016). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

6 years, 11 months

Re: [TUHS] Swapping (Was: !mail tuhs@minnie.tuhs.org)

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy >> From: Paul Ruizendaal >> LSX has a maximum of three processes that are swapped in and out in a >> stack-like fashion. Only one process is ever in core. I'm having a hard time working out how this works. If process A is swapped out, and then B, B has to be swapped in before A can be? But only one process is ever in core at a time? To get A in, B has to be moved out? But then B would be the last one out, and would have to come in before A? Anyway, I don't understand why the OS could/would care which order processes we swapped in - unless it's something like the 'onion skin' memory allocation algorithm of CTSS (which also had only a single process resident at a time, IIRC), where, when a small process had to be swapped in, and a large one was already in, it only swapped out enough of the large one to make room for the small one. The process could recurse, hence the name. > V1 was a time-sharing system; for which LIFO swapping is > inappropriate. And I don't follow that either... V1 ran on the 11/20 without memory management hardware, though, right? (Although there's that cryptic reference to the KS11 in "Odd Comments and Strange Doings in Unix", although I've never been able to find out anything else about the KS11.) So presumably one would not have wanted more than one process resident at a time, as that decreases the odds of a buggy program trashing another process? Noel

6 years, 11 months

origin of C header files

by Wesley Parish

Hi I've just had an interesting experience, explaining C header files to a nephew programmer who didn't understand them. I pointed him in the direction of Minix as an example of a small well-engineered system which would display their use. Which raised the question: when did header files come into use? Who was the first to use header files to store common system-wide or application-wide data definitions? Was it used in any languages prior to C? Thanks Wesley Parish

6 years, 11 months

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 January 2018