TUHS

tuhs@tuhs.org

28 participants
6416 discussions

by Pat Barron

Long ago, I could swear I'd read a paper (or a TM, or something) that described the process of a Unix system booting. It presented a timeline describing the sequence of how the boot blocks are loaded, the kernel is loaded, MMU turned on, etc. However, other than that, I can't recall a thing about it - can't remember the title, the author, or where I found it. I don't remember if it talked about this process on a Bell Labs Unix system, or a BSD system (though it had to be one of those - either 7th Edition or BSD). The timeframe was probably mid to late 1980's, though I could be wrong about that. Does this ring a bell with anyone? I really wish I could find it again... --Pat.

5 years, 9 months

Talk about some interesting things about Dennis

by Norman Wilson

What is Dennis's character? Is he very humorous? Thank you. He was more humorous when he was still alive, but I think he would have appreciated this joke. Norman Wilson Toronto ON

5 years, 9 months

Talk about some interesting things about Dennis

by Caipenghui

Hello, everyone! Can you share some interesting things around Dennis? What is Dennis's character? Is he very humorous? Thank you. Caipenghui

5 years, 9 months

Re: [TUHS] Paper discussing Unix boot process?

by Paul Ruizendaal

Maybe xv6 has an explanation of the boot process that is of use to the original poster: https://pdos.csail.mit.edu/6.828/2018/xv6.html Paul

5 years, 9 months

Re: [TUHS] Paper discussing Unix boot process?

by jnc＠mercury.lcs.mit.edu

> From: Charles Anthony > The Multics System Initialization Program Logic Manual. 139 pages of > somewhat detailed information. I was going to mention the Multics init PLM! :-) Needless to say, it's probably not a good candidate for the original goal - a document describing how an OS boots - it's simply too complicated for ordinary mortals! (Reading it makes _my_ head hurt!) There are a couple of reasons it's so complex. Multics is not a monolitic OS, the way most versions of Unix are (although I gather this is no longer quite true of Linux); the OS isn't this large blob of bits you load into memory and start. Its structure makes heavy use of the segmentation model supported by the hardware. Moreover, although the first segments loaded aren't paged, many of the later ones are. (This makes sense in the context of the times; with limited core main memory, you wouldn't want to devote massive chunks of main memory to have the entire OS always resident.) However, this all makes for a more complex booting process; the standard Multics boot tape (a Multics System Tape) contains many modules, which get linked in individually at boot time. (In V6 terms - the version I'm most familiar with - it's as if a Unix boot tape contained 'lib1' and 'lib2', and the bootstrap included a linker to build the OS binary in memory.) And in fact the modules come in in tranches, and some of the earlier one are available for use in loading later tranches (e.g. paging). This does have some advantages, though; e.g. the MST is the same for all Multics machines (including the initial boot of a new machine); the system is customized to the particular configuration during the bootstrap process. This is actually not too crazy, there are reasons this makes sense. For one, the whole 'information utility' concept (where Multics admittedly went down the wrong path, in terms of the future of computers); a single giant machine (multi-processor, multi-memory bank, multi-I/O controller). The thing is that any of these could be switched out if it developed a fault, but then you have to be able to boot that new configuration. (In particular, Multics wasn't a master-slave multi-processor system, they're all the same; but only one CPU runs for most of booting, the others are started and added once the system is running. But the 'bootstrap CPU' might change if the original bootstrap CPU develops a fault...) Noel

5 years, 9 months

Also, VCF SE

by Warren Toomey

And Earl Baugh just let me know: VCF SE at the end of April will have Douglas McIlroy coming to speak. We also will have a number of Unix exhibits as well. Unix is the topic of the front of the show shirt. Earl http://vcfed.org/wp/festivals/otherevents/vintage-computer-festival-southea…

5 years, 9 months

Re: [TUHS] Paper discussing Unix boot process?

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey <wkt(a)tuhs.org> > That's all I knew at the time :-) :-) I used nroff/troff for a bit, but I didn't like it; I don't recall why, but I suspect I wasn't using people's macro packages, which probably made it more difficult to use. My favourite was SCRIBE, but it alas seems to have died. > From: Dan Cross <crossd(a)gmail.com> >> the original Western Electric copies are not troff'ed and run through >> a typesetter ... > Indeed. Even the mid-90's Peer-to-Peer press reprinting appears to be, > roughly, a facsimile of line printer output. ... > Interestingly, the title page appears to be approximately original and > is typeset. I finally located my copy of the reprint (I'd been using it to help Fritz Mueller find a problem in his RK11C, and it wasn't in its normal place), and comparing it with my 'samizdat' set (which came from a set owned by Lincoln-Sudbury High School - they actually had an -11 running V6, I helped their computer person, I forget his name now, with it), I can confirm that: - The reprint does mostly reproduce the exact page images from the original (which was indeed, mostly line-printer out), except that the original does not have the typeset chapter/section header pages. It's possible that the pages in the reprint are a new printing, but if so, they have exactly matched not only the layout (not too hard) of the original, but also the font. - In a couple of places (e.g. Contents, pg. 1; Preface, pg. 1; Chapter One, pg. 1) "UNIX" has been replaced by "UNIX*" (different font), and at the bottom of the page has been added "* UNIX is a Trademark of Bell Laboratories", again in a different font. - The typeset 'Source Code' title page is in the original; the copy in the reprint is an exact image, except that the upper-case "This information ... Written permission of Bell Laboratories" section is not in the original, which says instead at that place: "This document may contain information covered by one or more licenses, copyrights and non-disclosure agreements. Circulation of this document is restricted to holders of a license for the UNIX Software System from Western Electric. All other circulation or reproduction is prohibited." - The typeset 'Commentary' title page is different in my samizdat First Edition original; it's a copy of the other title page, except that the second para is replaced by the first sentence of the 'Commentary' title page of the reprint, and of course the title is different from the other volume. Noel

5 years, 9 months

Re: [TUHS] "Fork considered harmful"

by jnc＠mercury.lcs.mit.edu

> From: Richard Salz > Any view on this? > https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/ Having read this, and seen the subsequent discussion, I think both sides have good points. What I perceive to be happening is something I've described previously, but never named, which is that as a system scales up, it can be necessary to take one subsystem which did two things, and split it up so there's a custom subsystem for each. I've seen this a lot in networking; I've been trying to remember some of the examples I've seen, and here's the best one I can come up with at the moment: having the routing track 'unique-ID network interface names' (i.e. interface 'addresses') - think 48-bit IEEE interface IDs' - directly. In a small network, this works fine for routing traffic, and as a side-benefit, gives you mobility. Doesn't scale, though - you have to build an 'interface ID to location name mapping system', and use 'location names' (i.e. 'addresses') in the routing. So classic Unix 'fork' does two things: i) creates a new process, and ii) replicates the environment/etc of an existing process. (In early Unix, the latter was pretty simple, but as the paper points out, it has now become a) complex and b) expensive.) I think the answer has to include decomposing the functionality of old fork() into several separate sub-primitives (albeit not all necessarily directly accessible to the user): a new-process primitive, which can be bundled with a number of different alternatives (e.g. i) exec(), ii) environment replication, iii) address-space replication, etc) - perhaps more than one at once. So that shell would want a form of fork() which bundled in i) and ii), but large applications might want something else. And there might be several variants of ii), e.g. one might replicate only environment variables, another might add I/O channels, etc. In a larger system, there's just no 'one size fits all' answer, I think. Noel

5 years, 9 months

"Fork considered harmful"

by Richard Salz

Any view on this? https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/

5 years, 9 months

Re: [TUHS] Unix filesystem semantics history - files with holes

by Richard Tobin

> When did the Unix filesystem add the semantics for "files with holes" (large, > sparse files)? It was there in the first edition: https://www.bell-labs.com/usr/dmr/www/pdfs/man51.pdf The FILE SYSTEM (V) man page includes a last paragraph identical to that of FILSYS (V) in seventh edition: If block b in a file exists, it is not necessary that all blocks less than b exist. A zero block number either in the address words of the the i-node or in an indirect block indicates that the corresponding block has never been allocated. Such a missing block reads as if it contained all zero words. The first edition indirect blocks were a bit different though: if the file was bigger than 8 blocks (4kB), all the blocks in the inode were (singly) indirect. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

5 years, 9 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