From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 14493 invoked from network); 12 Apr 2020 09:27:09 -0000 Received-SPF: pass (minnie.tuhs.org: domain of minnie.tuhs.org designates 45.79.103.53 as permitted sender) receiver=inbox.vuxu.org; client-ip=45.79.103.53 envelope-from= Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with UTF8ESMTPZ; 12 Apr 2020 09:27:09 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id A980594497; Sun, 12 Apr 2020 19:27:07 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id D17FA94488; Sun, 12 Apr 2020 19:26:49 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=planet.nl header.i=@planet.nl header.b="hMz0TdD2"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 98F7D94488; Sun, 12 Apr 2020 19:26:47 +1000 (AEST) Received: from cpsmtpb-ews10.kpnxchange.com (cpsmtpb-ews10.kpnxchange.com [213.75.39.15]) by minnie.tuhs.org (Postfix) with ESMTP id 601D594486 for ; Sun, 12 Apr 2020 19:26:46 +1000 (AEST) Received: from cpsps-ews28.kpnxchange.com ([10.94.84.194]) by cpsmtpb-ews10.kpnxchange.com with Microsoft SMTPSVC(8.5.9600.16384); Sun, 12 Apr 2020 11:26:45 +0200 X-Brand: 7abm2Q== X-KPN-SpamVerdict: e1=0;e2=0;e3=0;e4=(e1=10;e3=10;e2=11;e4=10);EVW:Whi te;BM:NotScanned;FinalVerdict:Clean X-CMAE-Analysis: v=2.3 cv=Xq1hxWN9 c=1 sm=1 tr=0 cx=a_idp_e a=YnLMpE5S06+Zisl5ga1zfg==:117 a=soxbC+bCkqwFbqeW/W/r+Q==:17 a=x1i13A_MHe4A:10 a=IkcTkHD0fZMA:10 a=cl8xLZFz6L8A:10 a=AoeSMSUmAAAA:8 a=Yh1xwgSEc-NRfyHKd2EA:9 a=QEXdDO2ut3YA:10 a=IA4qIw_M-6cA:10 a=2UY7SMgi64q-0UtCmZ5F:22 X-CM-AcctID: kpn@feedback.cloudmark.com Received: from smtp.kpnmail.nl ([195.121.84.46]) by cpsps-ews28.kpnxchange.com over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Sun, 12 Apr 2020 11:26:44 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=to:date:message-id:subject:mime-version:content-type:from; bh=yUWYZEgYlCyvO9TbBPKOr1FdOlJZawE1qk2jMat4yWE=; b=hMz0TdD2K9oNeRJEowia4R18t8rFGt590Zrh/lBOoBj0nIoPcS/seLmm10ZY3bBCGBjf15nIr1W+2 r712RVu1+hH5lW6PJXiCJS5+4CUAbs6v9EmdjbnL1o4kPrRhhsiKT5MaN86HingJlySJWb/CSFzRj8 2Dnw2teKX7ewvQwI= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|dEdHVhnonUiSCFHP1kuHs0M287qmDU2rjOX6vCaZUy5x2rh6l3xWm9PoT/UWh7T cJ517ABJPYBz1uMMJCMDqew== X-Originating-IP: 80.101.112.122 Received: from mba2.fritz.box (sqlite.xs4all.nl [80.101.112.122]) by smtp.kpnmail.nl (Halon) with ESMTPSA id b9a6bce0-7c9f-11ea-bd55-005056ab7584; Sun, 12 Apr 2020 11:26:44 +0200 (CEST) From: Paul Ruizendaal Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <60425F60-2759-423B-8C8F-916BF14CC221@planet.nl> Date: Sun, 12 Apr 2020 11:26:44 +0200 To: TUHS main list X-Mailer: Apple Mail (2.3445.104.11) X-OriginalArrivalTime: 12 Apr 2020 09:26:44.0975 (UTC) FILETIME=[7BB2E7F0:01D610AC] X-RcptDomain: minnie.tuhs.org Subject: [TUHS] V8, V9 and V10 now in the "Unix Tree" X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" 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=E2=80=99d 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=E2=80=99t mean disrespect, but I think the surviving sources = support Rob=E2=80=99s 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=3DV8/usr/sys/sys/vmmem.c = still has the top comment "/* vmmem.c 4.7 81/07/09 */=E2=80=9C= , 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=E2=80=99t 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=3DV8/usr/sys/h/param.h = (middle bit) https://www.tuhs.org/cgi-bin/utree.pl?file=3DV8/usr/sys/h/filsys.h (note = the union) https://www.tuhs.org/cgi-bin/utree.pl?file=3DV8/usr/sys/sys/alloc.c = (note 'if(BITFS(dev))=E2=80=99) And indeed the bitmap was fitted inside the 4KB superblock,=20 > 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.) >=20 > 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.