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 28403 invoked from network); 16 Feb 2021 20:00:34 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 16 Feb 2021 20:00:34 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 75FC39CA71; Wed, 17 Feb 2021 06:00:32 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 2A8989C853; Wed, 17 Feb 2021 05:59:39 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 037219C853; Wed, 17 Feb 2021 05:59:37 +1000 (AEST) Received: from fourwinds.com (fourwinds.com [63.64.179.162]) by minnie.tuhs.org (Postfix) with ESMTPS id EDE039C83A for ; Wed, 17 Feb 2021 05:59:34 +1000 (AEST) Received: from darkstar.fourwinds.com (localhost [127.0.0.1]) by fourwinds.com (8.15.2/8.15.2) with ESMTPS id 11GJxWUx676466 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for ; Tue, 16 Feb 2021 11:59:32 -0800 Received: from darkstar.fourwinds.com (jon@localhost) by darkstar.fourwinds.com (8.15.2/8.15.2/Submit) with ESMTP id 11GJxWC5676454 for ; Tue, 16 Feb 2021 11:59:32 -0800 Message-Id: <202102161959.11GJxWC5676454@darkstar.fourwinds.com> From: Jon Steinhart To: TUHS main list In-reply-to: References: <202102151956.11FJuRIh3079869@darkstar.fourwinds.com> Comments: In-reply-to Tom Ivar Helbekkmo message dated "Tue, 16 Feb 2021 09:15:37 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <676452.1613505572.1@darkstar.fourwinds.com> Content-Transfer-Encoding: 8bit Date: Tue, 16 Feb 2021 11:59:32 -0800 X-JON-SPAM: local delivery Subject: Re: [TUHS] Abstractions 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" Tom Ivar Helbekkmo writes: > Jon Steinhart writes: > > > So if y'all are up for it, I'd like to have a discussion on what > > abstractions would be appropriate in order to meet modern needs. Any > > takers? > > A late friend of mine felt strongly that Unix needed an SQL interface to > the kernel. With all information and configuration in a well designed > schema, system administration could be greatly enhanced, he felt, and > could have standard interaction patterns across components -- instead of > all the quirky command line interfaces we have today, and their user > oriented output formats that you need to parse to use the data. > > sysctl done right, so to speak. OK, that's interesting and makes my brain a bit crazy. Are we talking select file_descriptor from file_table where file_name='foo' && flags='O_EXCL'; delete from process_table where process_id=pid; and so on? Lots of possibilities for weird joins. But, this wasn't exactly what I was looking for in my original post which was maybe too terse. There have been heated discussions on this list about kernel API bloat. In my opinion, these discussions have mainly been people grumbling about what they don't like. I'd like to flip the discussion around to what we would like. Ken and Dennis did a great job with initial abstractions. Some on this list have claimed that these abstractions weren't sufficient for modern times. Now that we have new information from modern use cases, how would we rethink the basic abstractions? Quoting from something that I wrote a few years ago: The original Apple Macintosh API was published in 1985 in a three-­ volume set of books called Inside Macintosh (Addison-­Wesley). The set was over 1,200 pages long. It’s completely obsolete; modern (UNIX-based) Macs don’t use any of it. Why didn’t this API design last? By contrast, version 6 of the UNIX operating system was released 10 years earlier in 1975, with a 321-page manual. It embodied a completely different approach that sported a narrow and deep API. Both the UNIX API and a large number of the original applications are still in widespread use today, more than 40 years later, which is a testament to the quality of the design. Not only that, but a large number of the libraries are still in use and essentially unchanged, though their functionality has been copied into many other systems. While I don't have a count of the number of entries in the original Mac API, I'm guessing that number of Linux system calls is getting closer to that number. Is there any way that the abstractions can be rethought to get us back to an API that more concise and flexible? By flexible I mean the ability to support new functionality without adding more system calls? While the SQL interface notion is interesting, to me it's more in line with using a different language to access the API. But it would be interesting to see it fleshed out because maybe the abstractions provided by various tables would be different. Because it's easy pickings, I would claim that the socket system call is out of line with the UNIX abstractions; it exists because of practical political considerations, not because it's needed. I think that it would have fit better folded into the open system call. Something else added along with the networking was readv/writev. In this case, I would claim that those are the correct modern abstraction and that read/write are a subset. Hope that clarifies the discussion that I'm trying to kick off. Jon