TUHS

tuhs@tuhs.org

6532 discussions

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

6 years, 2 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…

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

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

6 years, 2 months

"Fork considered harmful"

by Richard Salz

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

6 years, 2 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.

6 years, 2 months

Unix filesystem semantics history - files with holes

by Erik E. Fair

When did the Unix filesystem add the semantics for "files with holes" (large, sparse files)? Just an idle question that was sparked by a conversation I had today. Erik <fair(a)clock.org>

6 years, 2 months

Re: [TUHS] Paper discussing Unix boot process?

by Pat Barron

The more I think about this, the more I'm sure I'm barking up the wrong tree... >From bits and pieces I've been able to recall, the thing I am looking for was not about Unix - it was about TOPS-20. It was a timeline of the system bootstrap activities from power-on to the point where users could log in. I still don't remember where I found it originally, but at least now I'm pretty sure I've been looking in all the wrong places... I believe it originated at CMU, but I don't know for sure that that's where I originally located it. The actual problem I'm trying to solve is, at this point in my professional career, I'm starting to interact with a lot of people (even experienced software developers) who just have no clue of what has to happen to get a computer from the point of "power-on" to the point where they can actually use it to do things. This makes me sad... So, I'm looking for something that I can point these people to that could clue them in... I think the whole bootstrap process is useful to understand for a lot of reasons, partly because it makes you think about all the little fiddly details that have to be attended to to make the computer do what you want - when I was first learning about this, I remember being particularly fascinated by what had to happen to prepare for that moment at which you turn on the MMU, to make sure that the system continues executing in a place you expect it to, in the right processor mode. I know most people that I interact with are using Linux or Windows on Intel-architecture machines, but the boot process for Unix on the PDP-10 or VAX (or even TOPS-20 on the PDP-10) I thought would be a much simpler thing to understand. Though maybe that's the wrong thought process, maybe I should just find something related to Linux that is comparable (even though I think it's more complicated). While searching, I also came across a decent presentation by a friend of mine who teaches at CMU, and discusses hardware that people probably actually work with right now, but I think it would be best consumed along with the actual lecture that it goes with. http://www.cs.cmu.edu/~410-f08/lectures/L20_Bootstrap.pdf Maybe I'll find what I was originally looking for at some point, but after spinning on this for most of the day, I don't think it's related to Unix... --Pat.

6 years, 2 months

Re: [TUHS] TUHS Digest, Vol 41, Issue 2

by Doug McIlroy

here

6 years, 2 months

Re: [TUHS] List ping

by jnc＠mercury.lcs.mit.edu

This thread brings to mind a wonderful saying which I just saw in another forum: "A wise man speaks when he feels he has something to say - a fool speaks when he feels he has to say something." And to reply in advance to the 'but I did't realize so many other people had sent in replies' - try scanning your emailbox before replying to messages to a large list. S/N is to be hallowed. Noel

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