From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26802 invoked from network); 29 Jun 2020 16:35:48 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 29 Jun 2020 16:35:48 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 24DDE9C664; Tue, 30 Jun 2020 02:35:47 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id CD5FE9C190; Tue, 30 Jun 2020 02:34:56 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 659549C190; Tue, 30 Jun 2020 02:34:53 +1000 (AEST) Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by minnie.tuhs.org (Postfix) with ESMTPS id ECF6F945A4 for ; Tue, 30 Jun 2020 02:34:52 +1000 (AEST) Received: by mail-pg1-f182.google.com with SMTP id g67so7645459pgc.8 for ; Mon, 29 Jun 2020 09:34:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=gw3wEVGcU10SnAodFVbP0yHwjeL+sy4nNFzR1FnNykw=; b=J69kPLpBaTSYMKIXzAFNRl2vbWlzHq9Es5AwAQX+rQ6Sb5TciMP2h+vsyugKCFzzRz XwEI4w7t0aatD9IxTKti0v3zufEeB9F+OiwYu0GkiKdfJ2lNOBHhsdI2hAdKcmzIpCFi cGkHuNxMwdQG9duYcWZ5Bwjqwsvc84mEF7X3h0M1L/aPoC8mphekbR8FG5jLDkTRZqdw j9XBIkTPAvUj8DOAqhQ1Ck8ZnObJbnDKi9EVNmXVHhQUniqQMwj4fxub/OqP/P5nEA1M rp0w0mja7sDVwKgrq513te3umfpcmfGjrfBDIEen8bDtblqenWsf33ZQpmomSBoQfjEW AYjw== X-Gm-Message-State: AOAM532xmcHbS9EpWrJfyRSD79m+yhM9vOe9iw/evzvJzDvHfILD3IUj 2obOlo1M7FqdE05LvZjcYsmAILGCBh8= X-Google-Smtp-Source: ABdhPJx01bRaYjLBB/IG+hsAlJlukGVUsNIsp3EBgk/VWXJL5xwiv8m93DTxBZF7M+zsksv1zGtCqQ== X-Received: by 2002:a63:6741:: with SMTP id b62mr10924524pgc.58.1593448492080; Mon, 29 Jun 2020 09:34:52 -0700 (PDT) Received: from ?IPv6:2601:601:a000:cb0:64d4:c14f:ec42:b74c? ([2601:601:a000:cb0:64d4:c14f:ec42:b74c]) by smtp.gmail.com with ESMTPSA id h130sm202308pfe.200.2020.06.29.09.34.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Jun 2020 09:34:51 -0700 (PDT) To: tuhs@minnie.tuhs.org References: <888A9360-A6E0-4EE0-84A5-8ADD478807E1@planet.nl> From: Heinz Lycklama Organization: Open Systems Technology Associates Message-ID: <59a01bce-3076-f4db-acb1-99089faac01e@osta.com> Date: Mon, 29 Jun 2020 09:34:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <888A9360-A6E0-4EE0-84A5-8ADD478807E1@planet.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [TUHS] VFS prior to 1984 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: , Reply-To: heinz@osta.com Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" We implemented filesystems as a supervisor process so that it could support file access from both a UNIX supervisor process and an RSX/11 supervisor process in the MERT operating system. See Figure 1 in the MERT paper in the July/August 1978 BSTJ. Heinz On 6/29/2020 2:11 AM, Paul Ruizendaal wrote: > Date: Wed, 24 Jun 2020 14:31:34 -0400 (EDT) > From: norman@oclsc.org (Norman Wilson) >> Reaching outside of UNIX, RSX/11 used external supervisor-mode processes called ACPs (ancillary control processes) to implement file systems. I don't know exactly how they were plugged in, but I do know they were pluggable, so their interface must have constituted a file-system switch of some sort. RSX dates back into the 1970s. At some point in the latter part of the 1980s, Ralph Stamerjohn (a name instantly recognizable in the 16-bit DEC software world) gave a DECUS talk about implementing a remote file system through ACPs: a stub ACP on the client exporting RPCs over the network, a real one at the server end. I remember chatting with him about how that did and didn't resemble the way pjw had done it; interesting architectural comparison. >> Norman Wilson Toronto ON > I am still digesting all the inputs (thanks, all!) > > The above post made me realise that the delineation of what is a FSS/VFS or not, is not so easy. > > I did a little bit of reading, and the concept of an ACP arrived with RSX11D in May 1973, but only matured in RSX11M in November 1974. As I understand it, originally in RSX11 file system code was closely tied to the low-level device driver for each device. ACP’s separated the file system code from the device driver itself, and became separate processes. > > In essence there were two switches: one switch into abstract devices, implemented in ACP code and one kernel switch to deal with hardware interfacing. The first is indeed like a file system switch (although still tied to specific devices). > > Looking at this stuff made me realise that my retro machine of choice (the TI990) went through a similar evolution. In the early seventies it had a sort of abstract device switch that linked to individual ‘device service routines’ (drivers). Initially, these modelled batch oriented ‘logical units’ that tied to files at the job control level. Later (late 70’s), the ‘open’ command would carry a file name and the file system was delegated to the device service routine. Still later (say 1983) this was used for networked disks. > > As several people have observed in this topic, indeed there appears to be a close relationship between a device switch and a file system switch. > > > >