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,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 18706 invoked from network); 12 Apr 2020 10:01:38 -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 10:01:38 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id BAAE6944C4; Sun, 12 Apr 2020 20:01:36 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id F224494488; Sun, 12 Apr 2020 20:01:12 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Gg7xMTzx"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 39DF594488; Sun, 12 Apr 2020 20:01:11 +1000 (AEST) Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) by minnie.tuhs.org (Postfix) with ESMTPS id 18FBF94486 for ; Sun, 12 Apr 2020 20:01:09 +1000 (AEST) Received: by mail-ua1-f54.google.com with SMTP id a10so2153318uad.7 for ; Sun, 12 Apr 2020 03:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OoB5pZWjQnhEfZEg0EyT5FMduuUAGKTYFvHzOEoeceQ=; b=Gg7xMTzxBNMbN/itPkxWMNZJ3OKhsOGMYBLNqMk65x+IFw4NRVw/KB0J+N9f7qFf+M 0IHm6QSXPZu1JYdXDV61oU/IL9lkYo+BiCGXIlNAT/jFR4XS5dU9oOnbqfY8XIYcuj/+ HxfeEa0NaLT0w92NWPuIa2xX/2Y7BtNsE8aoRkRnOtAbB5A/KKpcVZLNLyhMFtWnlkyf w77gOseOGZFi788heTPDkQzyvnw1DCb/HJ62RWVc6UdufgBBvW2k5jooWqkGNzGdixL0 DwpQK+lP6QhNzdIOszqjvQOipobjeyMpRA90gN5clOWaXC2XLgR/G/k4HR5PxRO293bR wi9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OoB5pZWjQnhEfZEg0EyT5FMduuUAGKTYFvHzOEoeceQ=; b=qaMXpXyuBZhvksLJ8F0U77OGE7NthEok1L3JEmKnr6dbG9op/FgWGwmSbxzxrAAAfZ Mc+dgosxI6tDeqF8IVBMa5Br0iYbQLrat4cPqtzbzTs1llgMLIVfsl8Z5jnNSPzjRnaT 7qehs1Hs0+bniye49qvDMcJrF9Yg4Evt7OkqgZUAV8JzRD9cQitaJKF51ai7iAEBnbPi WHRcysZMl5n570P+cVs6QQpqBkMmg2/QJFIY3fuEiIYWGQNBB6FXURImbHURgBkhWZJi qdDWVOCcCUWYEjlMltqacJ2BHS94VEv0jGzC+buYL1OEqrpTkXAKQ9wbPSINdqjR8olI tmEw== X-Gm-Message-State: AGi0PuYyaivFvcmcd3JGQ2sKyWR407C+DhLvRp/N/o1f5xOlTaBQdpo+ FhucLpR4QPLeL6wdh5k9K+NgcdqU+gD1eluJjoHm2Py9 X-Google-Smtp-Source: APiQypKJGasn575Xc4Ms6GyNee0hy8gCi3R4v3OxLDAosLTBtsGp4oRTMyFqqSF2mV5SW5ciV2FmSlgseP8VYWFnyc0= X-Received: by 2002:a9f:3e99:: with SMTP id x25mr8195163uai.118.1586685667990; Sun, 12 Apr 2020 03:01:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Pike Date: Sun, 12 Apr 2020 20:00:56 +1000 Message-ID: To: Paul Ruizendaal Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [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: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" My favorite use of the file system switch was the "face server" (analogous to name server), documented in a paper by myself and Dave Presotto at the Portland USENIX in 1985. http://doc.cat-v.org/bell_labs/face_the_nation/ We believe this was the first networked delivery of facial images to indicate the sender of an arriving mail message. The associated vismon program was also of interest in what it showed, and how small the code was given the uniform system interface to resources. -rob On Sun, Apr 12, 2020 at 7:31 PM Paul Ruizendaal wrote: > > Oops - pressed send too soon - apologies > > =E2=80=94 > > 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 w= ay around. If it was the other way around somebody would have spent conside= rable 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 late= r. > > > 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 suppor= t 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 t= he 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 wit= h 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 du= ring the development of 8th Edition. > > As far as I can tell 4.1aBSD was released in March or April 1982. Unfortu= nately no source code tape of it has surfaced, and SCCS coverage at this po= int 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 comple= tely 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, 961 longs. > 961 x 32 bits x 4KB =3D 120MB > > I=E2=80=99m 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.) >