TUHS October 2021

tuhs@tuhs.org

36 participants
25 discussions

by norman＠oclsc.org

I can't speak to the evolution and use of specific groups; I suspect it was all ad-hoc early on. Groups appeared surprisingly late (given how familiar they seem now): they don't show up in the manual until the Sixth Edition. Before that, chown took only two arguments (filename and owner), and permission modes had three bits fewer. I forget how it came up, but the late Lee McMahon once told me an amusing story about their origin: Ken announced that he was adding groups. Lee asked what they were for. Ken replied with a shrug and `I dunno.' Norman Wilson Toronto ON

3 years, 2 months

Groups origins

by norman＠oclsc.org

Groups appeared surprisingly late (given how familiar they seem now): they don't show up in the manual until the Sixth Edition. Mea culpa; read too hastily. The change actually came with the Fourth Edition, at the same time as several other landmark system changes: -- Time changing from a 32-bit count of 60Hz clock ticks (which ran out so quickly that its epoch kept moving) to the modern 32 bits of whole seconds, based at 1970-01-01T00:00:00 GMT (which takes much longer to run out, though the horizon is now visible). -- The modern super-block. In 4/e, the super-block began at block 0, not 1 (so bootstrapping was rather more complicated); the free list was a bitmap rather than the later list of blocks containing lists of free block numbers. -- The super-block contained a bitmap of free i-numbers too. All told, the free block and free i-node map made up a 1024-byte super-block. -- I-numbers 1-40 were device files; the root directory was i-number 41. The only file-type indication in the mode word was a single bit to denote directory. It was already clear that the lifetime of the bitmaps was running out: the BUGS section says two blocks isn't enough for the bitmaps for a 20-megabyte RP02. Norman Wilson Toronto ON

3 years, 2 months

Groups origins

by Will Senn

Hi all, I was reading a recent thread, over on the FreeBSD forums about groups that quickly devolved into a discussion on the origin of the operator group: https://forums.freebsd.org/threads/groups-overview.82303/ I thought y’all would be the best place to ask the questions that arose in me during my read of the thread. Here they are in no special order: 1. Where did operator come from and what was it intended to solve? 2. How has it evolved. 3. What’s a good place to look/ref to read about groups, generally? I liked one respondent’s answer about using find, heir, and the files themselves to learn about groups being used in a running system, paying attention to the owner, Audi, etc along the way and this is how I do it now, but this approach doesn’t account for the history and evolution. Thanks! Willu Sent from my iPhone

3 years, 2 months

Re: [TUHS] Systematic approach to command-line interfaces

by Paul Ruizendaal

Greg wrote: > I guess pipe(2) kind of started this mess, [...] Maybe I'm > going to far with thinking pipe() could/should have just been a library > call that used open(2) internally, perhaps connecting the descriptors by > opening some kind of "cloning" device in the filesystem. At times I’ve been pondering this as well. All of creat/open/pipe could have been rolled into just open(). It is not clear to me why this synthesis did not happen around the time of 7th edition; although it seems the creat/open merger happened in BSD around that time. As to pipe(), the very first implementation returned just a single fd where writes echoed to reads. It was backed by a single disk buffer, so could only hold ~500 bytes, which was probably not enough in practice. Then it was reimplemented using an anonymous file as backing store and got the modern two fd system call. The latter probably arose as a convenient hack to store the two file pointers needed. It would have been possible to implement the anonymous file solution still using a single fd, and storing the second file pointer in the inode. Maybe this felt as a worse hack at the time (the conceptual split in vnode / inode was still a decade into the future.) With a single fd, it would also have been possible to have a cloning device for pipe’s as you suggest (e.g. /dev/pipe, somewhat analogous to the implementation of /dev/stdin in 10th edition). Arguably, in total code/data size this would not have been much different from pipe(). My guess is that from a 1975 perspective, creat/open/pipe was not perceived as something that needed fixing.

3 years, 2 months

Re: [TUHS] mmap origin (was Systematic approach to command-line interfaces)

by Paul Ruizendaal

Dan wrote: > 3BSD and I think 4.1BSD had vread() and vwrite(), which looked like > regular read() and write() but accessed pages only on demand. I was a > grad student at Berkeley at the time and remember their genesis. Bill > and I were eating lunch from Top Dog on the Etcheverry Hall plaza, and > were talking about memory-mapped I/O. I remember suggesting the actual > names, perhaps as a parallel to vfork(). I had used both TENEX and > Multics, which both had page mapping. Multics' memory-mapped segments > were quite fundamental, of course. I think we were looking for something > vaguely upward compatible from the existing system calls. We did not > leap to an mmap() right away just because it would have been a more > radical shift than continuing the stream orientation of UNIX. I did not > implement any of this: it was just a brainstorming session. Thank you for reminding me of these. On a substrate with a unified buffer cache and copy-on-write, vread/vwrite would have been very close to regular read/write and maybe could have been subsumed into them, using flags to open() as the differentiator. The user discernible effect would have been the alignment requirement on the buffer argument. John Reiser wrote that he "fretted” over adding a 6 argument system call. Perhaps he was considering something like the above as the alternative, I never asked. I looked at the archives and vread/vwrite were introduced with 3BSD, present in 4BSD but marked deprecated, and absent from 4.1BSD. This short lifetime suggests that using vread and vwrite wasn’t entirely satisfactory in 1980/81 practice. Maybe the issue was that there was no good way to deallocate the buffer after use.

3 years, 2 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 October 2021