TUHS

tuhs@tuhs.org

47 participants
6503 discussions

by Jacob Ritorto

Hiya! Got these two pdp11s, one an 11/23 (Ultrix-11 3.1) and the other an 11/84 (2.11BSD) On the Ultrix machine, I can enter an assembly language program, assemble it and run it fine. amnesiac# cat hello.s mov $1,r0 sys 4 a 6 sys 1 a: <Hello\n> amnesiac# od hello 0000000 000407 000022 000000 000000 000014 000000 000000 000000 0000020 012700 000001 104404 000014 000006 104401 062510 066154 0000040 005157 000000 000000 000000 000002 000000 000000 000000 0000060 000000 000000 000141 000000 000000 000000 000002 000014 0000100 amnesiac# ./hello Hello amnesiac# But on the BSD machine, the exact same source program assembles differently and crashes with Illegal instruction when I run it. > cat hello.s mov $1,r0 sys 4 a 6 sys 1 a: <Hello\n> > od a.out 0000000 000407 000022 000000 000000 000010 000000 000000 000000 0000020 012700 000001 104404 000014 000006 104401 062510 066154 0000040 005157 000000 000000 000000 000002 000000 000000 000000 0000060 000000 000000 000000 000004 000002 000014 000000 000006 0000100 000141 0000102 > ./a.out Illegal instruction (core dumped) > Anyone know what I'm doing wrong? thx jake

5 years

Re: [TUHS] v7 K&R C

by jnc＠mercury.lcs.mit.edu

> From: Rob Pike > Convenient though the shorthand may be, it always bothered me as > inconsistent and misleading. As someone who made very extensive use of procedure pointers (most notably in upcalls, which never caught on, alas), I couldn't agree more. Two very different things are happenging, but with the shorthand notation, they share an identical representation. And for what? To save three characters? Noel

5 years

Re: [TUHS] v7 K&R C

by jnc＠mercury.lcs.mit.edu

> From: Derek Fawcus > I think he means something like: > (*((*((*((*f)()->g))()->h))()->i))() So I've been confused by this thread, and I'm hoping someone can deconfuse me - but I think I may have figured it out. What's confusing me is that in C, the -> operator is followed by "an identifier [which] designates a member of a structure or union object" (I checked the spec to make sure my memory hadn't dropped any bits) - but g, h above are arguments; so I couldn't figure out what was going on. I think what may have happened is that initially the discussion was about C ("Pretty sure it was not in v7 C"), but then it switched to C++ - with which I'm not familiar, hence my confusion - without explicitly indicating that change (although the reference to Bjarne Stroustrup should been a clue). (And that's why I thought "f()->g()->h()->i()" was ad hoc notation for "calls f(), then calls g()".) Am I tracking now? Noel

5 years

Re: [TUHS] v7 K&R C

by jnc＠mercury.lcs.mit.edu

> From: Rob Pike > To make chaining of calls simpler. Write > f()->g()->h()->i() > the other way You mean: (*f)((*g)((*h)((*i)()))) I dunno, it doesn't seem that much worse to me. What I like about the explicit notation (i.e. (*f) ()) is that it forces the programmer to recognize what's going on. On the other hand, I guess, the whole concept of compiled languages is to get the programmer's nose out of the low-level details, so they can focus on the high level. So I guess one could see allowing f() in place of (*f)() as an instance of that. Then again, down that road you find a lot of modern code, where a programmer writes something that is e.g. horribly inefficient and slow, precisely because they are so divorced from the low-level of what the code they wrote turns into... Still, I'd be a little worried about a program doing (*f)((*g)((*h)((*i)()))), no matter what the notation was; it would be awfully hard to recognize what all the possible call chains are. But then again I guess a lot of e.g. AI code does things like that... Noel

5 years

Re: [TUHS] v7 K&R C

by jnc＠mercury.lcs.mit.edu

> From: moanga >> To make chaining of calls simpler. Write >> f()->g()->h()->i() Ah; I was confused by his notation; I didn't realize he meant the C operator '->'. Noel

5 years

v3 pipes

by Paul Ruizendaal

>> why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication. > My understanding is that the single file descriptor broke the open-file > model, which had a single read/write pointer. Two-way communication via I’m not sure I understand. In the implementation, the read pointer is file location offset (“fp->f_offset”) and the write pointer is the file size (“ip->i_size”). The location offset on the writing end of the pipe is always zero, and on the reading end it moves between zero and PIPSIZ (but that is unobservable). I just tried making both pipe ends readable+writeable in my “V6.5” kernel and that appears to work. It allows for bi-directional communication in a half-duplex sense (i.e communicating walky-talky style). The other benefit is using just one file descriptor, at a time when a process had just 15 to work with. Maybe the issue was that two sides writing to a full pipe at the same time will cause deadlock?

5 years

Re: [TUHS] Plan 9 from outer space ?

by norman＠oclsc.org

I asked a friend who was around at the time (I think he and Rob worked together at times). Here's what he recalls: I'll keep it going. rc was a description that it was the worst movie ever. And was for many years listed as the worst system ever (except for all the others) in a mish-mash of creative naming... I have no clue if this is true, and I'm honestly having trouble recalling his name. It wasn't my intention. There was a description that it was a startup script from very early times in Unix, shortened, as Ken was wont to do, from runcom, the nearest thing CTSS had to a shell--it could run up to six prespecified commands in background. It wasn't a 'big name' like Evi, but I don't know if I buy it, that plan 9 from outer space poster hanging. Plan 9 from Bell Labs as all these themes flowed together in a mish-mash of creative naming... With a different name, it could be the lack of information, those who guess at reasons for naming generate volumes of apocrypha. The real reason is usually, ``because''.* Trust me, there are even worse movies... Someone posted some pictures of the names tell you anything helpful. Despite the lack of televised sports getting to me in these shelter-in-place days, but, I mean, sure, I guess I'll throw in some bucks for a pay-per-view of a Pike/Thompson cage match. FIGHT! Followups set. Things are named usually because the name is "Plan 9 from outer space poster hanging. None of the office area at Murray Hill to this list. Plan 9 is the worst system ever (except for all the others) in a knod to Churchill (supposedly based on his comment about Democracy). And from there it was 25 years ago and beer was involved). It makes a great story, but I don't think there's much doubt about it. And was for many years listed as the worst movie ever, including the formative years of plan 9. Yes, but is there anything besides the name? There is a widespred anecdote that "Plan 9" name comes from the movie until the end (what a pain!). _-_-_-_-Mark Norman Wilson Toronto ON

5 years, 1 month

Re: [TUHS] v3 pipes

by Doug McIlroy

> why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication. My understanding is that the single file descriptor broke the open-file model, which had a single read/write pointer. Two-way communication via Doug

5 years, 1 month

V3 pipes

by Paul Ruizendaal

Was looking into pipes. For the 3rd Edition TUHS does not have source, but is does have a man page. In V3, pipe returns a single file descriptor that echoes whatever is written back upon reading. The pipe buffer capacity is 504 bytes. The surviving ‘nsys’ source for V4 does not yet include the source for pipes, but the man page for 4th edition pipes has - more or less - the well known semantics, including the 4096 byte buffer capacity. Does anyone remember: - why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication. Maybe the reason was that it becomes harder to detect broken pipes? - whether the V3 implementation was based on an in-memory approach and not the later 'anonymous backing file’? The 504 byte buffer capacity suggests a single buffer page minus some header info.

5 years, 1 month

Off Topic: Unix Kermit 4x software archeology

by Warner Losh

Greetings, So this happened: https://bsdimp.blogspot.com/2020/04/finding-kermit-4x.html tl;dr: while obsessing over 4C(052) kermit that's in Rainbow Venix, I found a lot of cool "lost" source code versions of Kermit... All except the one I was looking for. Warner

5 years, 1 month

8th Edition and /dev/stdio

by Paul Ruizendaal

Whilst spelunking in the V8 source code I came across this dozen lines: http://chiselapp.com/user/pnr/repository/v8unix/artifact/2782d26fa2930724?l… It implements the /dev/stdin, /dev/stdout and /dev/stderr devices (the variable ‘file_no’ in above code snippet is the constant 40, which is the major number of these devices). It would seem that this handful of lines could have been in Unix as early as 4th Edition — but they weren’t. Maybe it was not seen as useful. As far as I can tell this bit of code originates in 8th Edition, with no earlier precursors. It does not seem to be in its man pages. Who added this neat little innovation?

5 years, 1 month

Usenix tapes

by Warner Losh

So in the archives we have tapes from 1977, 1980-83 and 1987-89. So I thought I'd ask if there's other tapes that aren't in the archive... google can't even find the tapes we have in our archive, let alone others... Warner

5 years, 1 month

Re: [TUHS] Plan 9 from outer space ?

by Doug McIlroy

I'll keep it going. rc was a startup script from very early times in Unix, shortened, as Ken was wont to do, from runcom, the nearest thing CTSS had to a shell--it could run up to six prespecified commands in background. The name runcom came to be applied to the scripts as well as to their interpreter. Doug ------------------------------------- It wasn't my intention. -rob On Sun, Apr 19, 2020 at 11:12 AM Ken Thompson <ken(a)google.com> wrote: > > rob, > you shouldn't have shut down this discussion.

5 years, 1 month

Re: [TUHS] Plan 9 from outer space ?

by Rob Pike

It wasn't my intention. -rob On Sun, Apr 19, 2020 at 11:12 AM Ken Thompson <ken(a)google.com> wrote: > > rob, > you shouldn't have shut down this discussion. > > > On Sat, Apr 18, 2020 at 3:27 PM Rob Pike <robpike(a)gmail.com> wrote: >> >> As it says there, >> >> The hermeneutics of naming yields few insights. Things are named usually because the name is nice (sam), or there is some private reference hard to decode (8½), or in honour (perhaps backhanded) of another system (mothra), or an indication of expectation (Plan 9, acme), or just because (acid). None of the names tell you anything helpful. >> >> Despite the lack of information, those who guess at reasons for naming generate volumes of apocrypha. The real reason is usually, ``because''. >> >> -rob >> >> >> >> On Sun, Apr 19, 2020 at 3:50 AM Royce Williams <royce(a)techsolvency.com> wrote: >>> >>> On Sat, Apr 18, 2020 at 9:45 AM Warner Losh <imp(a)bsdimp.com> wrote: >>>> >>>> >>>> On Sat, Apr 18, 2020 at 11:24 AM Pierre DAVID <pdagog(a)gmail.com> wrote: >>>>> >>>>> On Sat, Apr 18, 2020 at 06:20:18PM +0100, Richard Tobin wrote: >>>>> >> There is a widespred anecdote that "Plan 9" name comes from the >>>>> >> movie "Plan 9 From Outer Space". >>>>> > >>>>> >Given that the full name is "Plan 9 from Bell Labs" I don't think >>>>> >there's much doubt about it. >>>>> > >>>>> >>>>> Yes, but is there anything besides the name? >>>> >>>> >>>> Plan 9 is the worst movie ever. And was for many years listed as the worst movie ever, including the formative years of plan 9. >>>> >>>> A professor(?) at CU once told me, though I don't know if I buy it, that plan 9 was Unix Plan B at first. There was a description that it was the worst system ever (except for all the others) in a knod to Churchill (supposedly based on his comment about Democracy). And from there it was a quick jump to Plan 9 from Bell Labs as all these themes flowed together in a mish-mash of creative naming... With a different name, it could break with Unix in interesting ways... >>>> >>>> I have no clue if this is true, and I'm no longer in contact with the professor that told me this since it was mid to late 90s, and I'm honestly having trouble recalling his name. It wasn't a 'big name' like Evi, but I think it was someone at CU I had a beer with (which means it could have been a grad student to post-doc as well, it was 25 years ago and beer was involved). It makes a great story, but I don't know if it's anything more than that. I put it out there because I know Rob or Ken is likely to correct something that's this detailed and specific if it's really wrong :) >>> >>> >>> See also: >>> >>> http://9p.io/wiki/plan9/lfaq/index.html#GENERAL_INFORMATION >>> >>> Royce

5 years, 1 month

Re: [TUHS] Plan 9 from outer space ?

by Richard Tobin

> There is a widespred anecdote that "Plan 9" name comes from the > movie "Plan 9 From Outer Space". Given that the full name is "Plan 9 from Bell Labs" I don't think there's much doubt about it. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

5 years, 1 month

Plan 9 from outer space ?

by Pierre DAVID

There is a widespred anecdote that "Plan 9" name comes from the movie "Plan 9 From Outer Space". Since I didn't find anything more than a reference to this anecdote (see https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs for example), I forced myself to watch the movie until the end (what a pain!). Guess what? I couldn't find the link between the film and the beloved OS. I'm sure there are people here who know more. Thanks in advance for sharing your knowledge with us. Pierre

5 years, 1 month

"7th Edition UNIX TM Summary" => "â7th Edition UNIX â Summaryâ => â€œ7th Edition UNIX â€” Summaryâ€

by Don Hopkins

I love how in a discussion of how difficult it was to publish a book on Unix with the correct punctuation characters 42 years ago, we still can’t even quote the title of the book in a discussion about Unix without the punctuation characters degrading and mutating each round trip. Worse truly is better! ;) -Don

5 years, 1 month

Early Datakit - Summary of findings

by Paul Ruizendaal

I’ve posted a summary of my Datakit notes here: https://drive.google.com/open?id=1p6HD5-NSAYKfiXL6GUxfYZgGoesqG6Sp (available for a limited time) Hopefully, these notes are helpful for anyone trying to figure out Datakit networking in Eighth Edition. At the user level, access is organised through the ‘dkdial’ and ‘dkmgr’ routines: http://man.cat-v.org/unix_8th/3/dkmgr http://man.cat-v.org/unix_8th/3/tdkdial The IP networking is handled in the same pattern: http://man.cat-v.org/unix_8th/3/tcp http://man.cat-v.org/unix_8th/3/udp The ipc set of library routines that unify these lower level routines into a single API will only appear in 9th Edition (a year later).

5 years, 1 month

4.2BSD Steering committee

by Paul Ruizendaal

According to “20 years of BSD”, there was a steering committee to inform the development of what would eventually be 4.2BSD Unix. The committee had the following members: Duane Adams and Bob Baker: DARPA Bob Fabry, Bill Joy, Sam Leffler: CSRG Dennis Ritchie: Bell Labs Alan Nemeth, Rob Gurwitz: BBN Dan Lynch: ISI Keith Lantz: Stanford Rick Rashid: CMU Bert Halstead: MIT Jerry Popek: UCLA I’m intrigued by the composition and the rationale for each member. Some of it is obvious, some of it is not. According to “20 years of BSD” what DARPA wanted was: "In particular, the new system was expected to include a faster file system that would raise throughput to the speed of available disk technology, support processes with multi-gigabyte address space requirements, provide flexible interprocess communication facilities that allow researchers to do work in distributed systems, and would integrate networking support so that machines running the new system could easily participate in the ARPAnet." As I understand Duane Adams was the contract manager and Bob Baker a DARPA vice-president. The CSRG crowd are also clear, they were going to do the work. Then it becomes less clear. I can certainly see the logic of asking dmr to provide his guidance, also in view of Bell Labs expertise in working with large scale communication systems. I can also see the logic of having the BBN and ISI folk there, representing the Arpanet community and doing the work on the new TCP/IP protocol stack. I’m not sure about the four others. They seem to be one each for 4 main computer science schools in the US at the time. Rashid and Popek had moreover recently completed distributed systems (Aleph and LOCUS). Halstead seems to have been working on messaging systems at the time. I’m not sure what Lantz’ spike was at the time. All in all, a strong focus on distributed systems and messaging. No people with apparent links to virtual memory research or disk access research. Other than dmr, no research people from industry. For example, nobody from Xerox Parc. Nobody from IBM, HP, DEC, DG, etc. Any and all recollections about the committee and its composition welcome.

5 years, 1 month

First book on Unix for general readership

by markus schnalke

Hoi, found on Wikipedia: As well as the Bourne shell, he wrote the adb debugger and The UNIX System, the second book on the UNIX system, intended for a general readership. https://en.wikipedia.org/wiki/Stephen_R._Bourne Thus I now wonder what the first book on Unix, intended for a general readership was. Bourne's book was published 1983. (``The UNIX Programming Environment'' was published 1984.) Was it Banahan and Rutter's ``UNIX -- the Book''? It says 1982. Could anyone share some background on that one? (The authors were from Bradford University.) I only have the German translation by Axel T. Schreiner, dated 1984. Haven't read the English original, but Schreiner's version definitely is worth to read (if you speak German). He added lots of footnotes, and it becomes apparent that he knows the system better than the authors. ;-) I'd like to get an understanding of the books in relation to each other. How does the Banahan/Rutter book fit into the picture? Why didn't Bell Labs write a user's book earlier? Were Bourne's and Kernighan/Pike's books reactions to it? meillo

5 years, 1 month

Re: [TUHS] First book on Unix for general readership

by Doug McIlroy

> OK, I've dug out my copies. They have perforated, 3-hole punched pages ... > I can't find any obvious typesetting errors. That sets my mind at rest after three decades. What I saw back in the day was littered with @ signs, and was not punched for a ring binder. Thanks for checking. Doug

5 years, 1 month

STREAMS performance

by Paul Ruizendaal

> Date: Sat, 11 Apr 2020 08:44:28 -0700 > From: Larry McVoy > > On Sat, Apr 11, 2020 at 11:38:44AM -0400, Norman Wilson wrote: >> -- Stream I/O system added; all communication-device >> drivers (serial ports, Ethernet, Datakit) changed to >> work with streams. Pipes were streams. > > How was performance? Was this Dennis' streams, not Sys V STREAMS? It was streams, not STREAMS. > I ported Lachmans/Convergents STREAMS based TCP/IP stack to the > ETA 10 Unix and SCO Unix and performance just sucked. Ditto for > the Solaris port (which I did not do, I don't think it made any > difference who did the port though). STREAMS are outside the limited scope I try to restrain myself to, but I’m intrigued. What in the above case drove/caused the poor performance? There was a debate on the LKML in the late 1990’s where Caldera wanted STREAMS support in Linux and to the extent the arguments were technical *), my understanding of them is that the main show stopper was that STREAMS would make ‘zero copy’ networking impossible. If so, then it is a comment more about the underlying buffer strategy than STREAMS itself. Did STREAMS also perform poorly in the 1986 context they were developed in? Paul *) Other arguments pro- and con included forward maintenance and market need, but I’m not so interested in those aspects of the debate.

5 years, 1 month

Re: [TUHS] First book on Unix for general readership

by Doug McIlroy

> Indeed the Unix manuals were available as printed books. Volume One was the manual pages and Volume Two the articles from /usr/doc. I remember seeing soft-cover bound copies of the 7th Edition manuals, ... > I think the next time this happened in the exact same way was with the "Unix Research System Tenth Edition" books published by Saunders College Publishing in 1990. Those were the only two that were published as trade books. I still use the 10th Ed regularly. The 7th Ed was a debacle. The publisher didn't bother to send us galleys because they had printed straight from troff. It turned out they did not have the full troff character set, and put an @ sign in place of each missing character. The whole print run was done before we saw a copy. Not knowing whether they ever fixed it, I'd be interested to hear whether or not the botch made it to bookstores. Doug

5 years, 1 month

V8, V9 and V10 now in the "Unix Tree"

by Paul Ruizendaal

Oops - pressed send too soon - apologies — Many thanks for the below notes! Some comments in line below: > The initial user-mode environment was a mix of 32V, > subsequent work within 1127, and imports from 4.1BSD. > I don't know the exact heritage: whether it was 1127's > work with 4.1BSD stuff added or vice-versa. Looking at the organisation of the source tree I’d say it is more likely that the base was V32 with bits of 4.1BSD imported than the other way around. If it was the other way around somebody would have spent considerable time to reorganise the source tree back to a form consistent with 32V. I think that such an effort would have been remembered even 40 years later. > The kernel was a clean break, however: 4.1xBSD for some > value of x (probably 4.1a but I don't remember which) > with Research changes. I don’t mean disrespect, but I think the surviving sources support Rob’s recollection that it was a gradual, ongoing effort. As a first approximation looking at the top comments of a file gives its origin: the BSD derived files still have an SCCS-type marker. For example the file https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/vmmem.c still has the top comment "/* vmmem.c 4.7 81/07/09 */“, even though it was last touched in 1985. (By the way, who knows which tool generated these comments? Is it early SCCS?) For the VM code, the BSD version stamp comment strings are consistent with the 4.1BSD release. For the TCP/IP stack they are consistent with 4.2BSD; it would seem probable to me that this code was imported multiple times during the development of 8th Edition. As far as I can tell 4.1aBSD was released in March or April 1982. Unfortunately no source code tape of it has surfaced, and SCCS coverage at this point is still very partial. I think 4.1b with the initial FFS implementation followed late summer 1982, I don’t have a more precise date (yet). > -- Berkeley FFS replaced by Weinberger's bitmapped > file system: essentially the V7 file system except > the free list was a bitmap and the blocksize was 4KiB. Thank you for pointing this out. With my focus on networking I had completely missed that. > Hacky implementation, depending on a flag bit in the > minor device number; didn't use the file system switch. > Old 512-byte-block file systems had to be supported > partly to ease the changeover, partly because the first > version had a limited bitmap size so file systems larger > than about 120MiB wouldn't work. For those interested, some of the relevant files are: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/param.h (middle bit) https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/filsys.h (note the union) https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/alloc.c (note 'if(BITFS(dev))’) And indeed the bitmap was fitted inside the 4KB superblock, 961 longs. 961 x 32 bits x 4KB = 120MB I’m not sure I understand the link between cluster and page size that is mentioned in param.h > This limit was removed > later. (In retrospect I'm surprised I didn't then insist > on converting any remaining old-format file systems in > our domain and then removing the old-format code from > the kernel, since user-mode tools--including a user-mode > file server!--could be used to access any old disks > discovered later.)

5 years, 1 month

V8, V9 and V10 now in the "Unix Tree"

by Paul Ruizendaal

Many thanks for the below notes! Some comments in line below: > The initial user-mode environment was a mix of 32V, > subsequent work within 1127, and imports from 4.1BSD. > I don't know the exact heritage: whether it was 1127's > work with 4.1BSD stuff added or vice-versa. Looking at the organisation of the source tree I’d say it is more likely that the base was V32 with bits of 4.1BSD imported than the other way around. If it was the other way around somebody would have spent considerable time to reorganise the source tree back to a form consistent with 32V. I think that such an effort would have been remembered even 40 years later. > The kernel was a clean break, however: 4.1xBSD for some > value of x (probably 4.1a but I don't remember which) > with Research changes. I don’t mean disrespect, but I think the surviving sources support Rob’s recollection that it was a gradual, ongoing effort. As a first approximation looking at the top comments of a file gives its origin: the BSD derived files still have an SCCS-type marker. For example the file https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/vmmem.c still has the top comment "/* vmmem.c 4.7 81/07/09 */“, even though it was last touched in 1985. (By the way, who knows which tool generated these comments? Is it early SCCS?) For the VM code, the BSD version stamp comment strings are consistent with the 4.1BSD release. For the TCP/IP stack they are consistent with 4.2BSD; it would seem probable to me that this code was imported multiple times during the development of 8th Edition. As far as I can tell 4.1aBSD was released in March or April 1982. Unfortunately no source code tape of it has surfaced, and SCCS coverage at this point is still very partial. I think 4.1b with the initial FFS implementation followed late summer 1982, I don’t have a more precise date (yet). > -- Berkeley FFS replaced by Weinberger's bitmapped > file system: essentially the V7 file system except > the free list was a bitmap and the blocksize was 4KiB. Thank you for pointing this out. With my focus on networking I had completely missed that. > Hacky implementation, depending on a flag bit in the > minor device number; didn't use the file system switch. > Old 512-byte-block file systems had to be supported > partly to ease the changeover, partly because the first > version had a limited bitmap size so file systems larger > than about 120MiB wouldn't work. For those interested, some of the relevant files are: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/param.h (middle bit) https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/h/filsys.h (note the union) https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/sys/alloc.c (note 'if(BITFS(dev))’) And indeed the bitmap was fitted inside the 4KB superblock, > This limit was removed > later. (In retrospect I'm surprised I didn't then insist > on converting any remaining old-format file systems in > our domain and then removing the old-format code from > the kernel, since user-mode tools--including a user-mode > file server!--could be used to access any old disks > discovered later.) > > For the purposes of Paul's note it probably suffices > just to say that there was a restart with a 4.1-series > kernel with changes as he describes, except also the > new file system format.

5 years, 1 month

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