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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29497 invoked from network); 24 Jun 2020 09:10:50 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 24 Jun 2020 09:10:50 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 66D44945AE; Wed, 24 Jun 2020 19:10:47 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id D13AE9459B; Wed, 24 Jun 2020 19:10:17 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="mp28xD9y"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 216F49459A; Wed, 24 Jun 2020 19:10:15 +1000 (AEST) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by minnie.tuhs.org (Postfix) with ESMTPS id B7C0A9459A for ; Wed, 24 Jun 2020 19:10:14 +1000 (AEST) Received: by mail-il1-f195.google.com with SMTP id c75so1370260ila.8 for ; Wed, 24 Jun 2020 02:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Ixv2dW7S8TZ8IaXCFgFmAEIHaL964B/epK1SDK2EbK8=; b=mp28xD9yQ/NpRPn73QdPrVTNysWnp4/P9SPy6S+8vkkFcQNw+nHQIkG34IyqoBWALF /h2cb62XXVQfht6Q3ZZr9xCTlZH4fesjpJcAFDS3FfXTvZnQ4VlGx49bHbddXe3BH8NZ qNo0ENcJiExzyXoEQvjCAWYww7TrdCfdaRQT2cWDmx+zqNErvymVo3N9hGpDCeFeJoK/ lsSVcM4VnAjI40faiAgD38XkBb9WnnrJNRhQUVfbMLnotRR86anEwtnO9mZtHAaF62MZ dpgGSF3XTEDMQCKNpc45m6y6849OataVfM0D+R/ai2bQrQ5/m6owHbRWlqfasKgwsUe4 OXFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Ixv2dW7S8TZ8IaXCFgFmAEIHaL964B/epK1SDK2EbK8=; b=sekgtsIWaYegzrVpUBEXEoImVN2+eY1WI7IIi5wpCkhLA6vpYGFUY2RYHFzcia8VKa UfS1Ntklio/kSirsQb4x+B2JXiLnx7YZygyswS538ER6v9JkghyBFLRHpMWB0KYXYV63 bAMDf7sDiG7WafwPfcwc0e6xiCHUGFt0R6KrpFjnJ8ohQTWULeTorcFFYjwhth6tFFvp /pjoe0T0VKysiUmpmVco2fFDZ9okhF1zFhpZ/ZiGYjB9KQYTgGK7+pBqzUWTgTkoj82+ eH3mp5pp78DRRskgO/wYbeJPZMbHzmIQOtbBnz9XYwRW51rlETb80ab+2kHETkhZDE0l gqBA== X-Gm-Message-State: AOAM5333L2jOdVAvuDcj2/1y6dgXObl1pnWBVxdhzET0bYid5xZFhUuB ApikttL1RdWK2Cy1C0sPia6DWT9XEbX8/UF2myW/Jg== X-Google-Smtp-Source: ABdhPJwxT1neq5yscLoy+xF4tmFv6Q8OX2uWjFIo9tXutObB9vsCZv9jOsDCoi72YTRvq2NX8eo9FC3vWQnhvPCF06s= X-Received: by 2002:a92:c7ab:: with SMTP id f11mr18103481ilk.50.1592989813626; Wed, 24 Jun 2020 02:10:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac0:c044:0:0:0:0:0 with HTTP; Wed, 24 Jun 2020 02:10:12 -0700 (PDT) In-Reply-To: References: <1592950638.2831.for-standards-violators@oclsc.org> From: Andrew Warkentin Date: Wed, 24 Jun 2020 03:10:12 -0600 Message-ID: To: The Eunuchs Hysterical Society Content-Type: text/plain; charset="UTF-8" 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 6/23/20, Bakul Shah wrote: > > The fact is that the Unix byte/block read/write model goes only so far. > Every device has its own peculiarities that need to be queried or > controlled. And then there are controllers or USB device treees where > you can hang useful devices at varius places. Bottom line: while dealing > with real devices you can push this complexity around. You can't make it > disappear. At one point a friend and I were looking at building a > product using plan9 and one of the things I wanted to do was to make > sure that the "ctl" file for every device responded to a "help" message > that yielded one line per command and "help " for more details. > That way you can discover their capabilities at runtime. > Yes, complexity is unavoidable. IMO, the reason for going with a purely file-oriented architecture isn't to make all user-visible APIs use normal file calls, even though they are all going to be implemented in terms of files (there's definitely a place for libraries that provide a friendlier API on top of the file-based transport). "Everything is a file" should not mean "all APIs are visibly file-based". The real advantages of a pure file-oriented architecture I can think of off the top of my head are basically: All security for all services in the system is enforced through a single mechanism (rather than having many security primitives like modern conventional OSes have) On a microkernel, a purely stream-oriented IPC transport layer will have better performance when dealing with bulk unstructured data than a structured RPC transport layer with dynamic marshalling invoked on every message (for servers that need RPC with dynamic marshalling, the transport layer can easily support a type of file that preserves message boundaries but otherwise has standard Unix semantics) A purely stream-oriented IPC transport layer is simpler than one with dynamic marshalling and has less attack surface All services in the system can be extended, overridden, and exported through the same mechanism (this includes making all parts of a purely file-oriented OS network transparent for basically free) In some cases a higher-level service that extends another one doesn't have to fully intercept all parts of the underlying interface (e.g. if the underlying interface has multiple files and only some need to be overridden, or possibly if some messages are treated as opaque)