From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 28a9206b for ; Wed, 31 Oct 2018 22:21:29 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id ABC79A217C; Thu, 1 Nov 2018 08:21:28 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 38D38A2152; Thu, 1 Nov 2018 08:20:56 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id F16DAA2152; Thu, 1 Nov 2018 06:57:50 +1000 (AEST) Received: from mail-vs1-f65.google.com (mail-vs1-f65.google.com [209.85.217.65]) by minnie.tuhs.org (Postfix) with ESMTPS id 7B383A214E for ; Thu, 1 Nov 2018 06:57:45 +1000 (AEST) Received: by mail-vs1-f65.google.com with SMTP id w194so10940464vsc.11 for ; Wed, 31 Oct 2018 13:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8fnDr6AAa8EXyZ+FB9lm1ZzzDHrXgHK4dDCi9VzOg+s=; b=tkIIHcpQVroS89NBGX9GRw3gVzREuo7a2xox2toocgPg5qYM5cTi3xvAaJk0JX0m/5 BsLCL0m4ePNNLQYYx3wIXdXVqYQRDoW+jXbS/qzSgFmpK7rlZhTdod5823vlhNtv2MDX im9BnSQ1LWxhEjXHe0OuH+9S7GJziVsLelQXEPGkIyt6yRVBV74t6SGZDwwUYudd3lNm KBCqOox+3GHOrnlYrACo1dRGGzg0ZACuY4xhh3+8JeUVtGVvAOjeW+EWhBGYb/Ws6uZM +ZuRwgTZLGhGW3hhdGO2J1fF36H5pUI7hSxeiYpSxAweTA12w5WF3KtPC1U7GhnIbJm7 6XPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8fnDr6AAa8EXyZ+FB9lm1ZzzDHrXgHK4dDCi9VzOg+s=; b=P/DfFb1F0M0vSwUmajd6GOaVLK4kqv0Ua8Dva0iH9GLeL5W23jLohBS1mTpjCajWib VO54TvtR8/Ji+heJslGJR6RGE708g9oTKbndoxsBCecPDHHUsZYYN3hoAQd54YavkLjF 5v06hb18nXOBinbKH1RmINWhpSSFYqXqUhUUWIAj63gg+4fZcReebRp8IET5bpBFPPYs qTurGPKwd1teRmNQ9MQuuoYdkWG7Gmty64W1jKu8Tt3zyubX5KASVu9sEs7OHMNWQwD9 RIx0An4Y5gKkYpGnWfUCEVhM4+iYtUVqN2/pfTW7xnD66JRqkMjN2j5mjghKQH4M4tQW cdNQ== X-Gm-Message-State: AGRZ1gLVQvhPvxt2Md54eS9tHORfWTnPzWzgvrfuJcwfQ/viXhiQNR0g pLhyM5C1ZsAlK3crOYhk7AZxVDjf X-Google-Smtp-Source: AJdET5csudVnFuAKev7iVRoan60xTH1GH0X6IisTX2hddMNZm0OKRbwAPuXf1I+yzwEimNKBhH+Bww== X-Received: by 2002:a67:7e41:: with SMTP id z62mr2075072vsc.141.1541019464014; Wed, 31 Oct 2018 13:57:44 -0700 (PDT) Received: from crack.deadbeast.net (rrcs-24-171-184-100.midsouth.biz.rr.com. [24.171.184.100]) by smtp.gmail.com with ESMTPSA id p191-v6sm4297427vkd.23.2018.10.31.13.57.42 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 31 Oct 2018 13:57:42 -0700 (PDT) Date: Wed, 31 Oct 2018 16:57:40 -0400 From: "G. Branden Robinson" To: tuhs@tuhs.org Message-ID: <20181031205738.vb2yba55cdrh5vdt@crack.deadbeast.net> References: <20181031043810.GA10775@minnie.tuhs.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dfychyqzfwqjlg4p" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Subject: Re: [TUHS] Unix APIs: elegant or not? X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 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" --dfychyqzfwqjlg4p Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable At 2018-10-31T11:47:20-0400, Paul Winalski wrote: > On 10/31/18, Warren Toomey wrote: > > > > The POSIX file API is a great example, but not of a deep > > interface. Rather, it=E2=80=99s a great example of how code with a ve= ry > > complicated interface may look deceptively simple when reduced to C-s= tyle > > function signatures. Indeed. It is my hope that in the coming years software engineers will decline to describe an interface as "simple" until they've seen how much logic is required to formally verify it. >=20 > For me one of the most important software design principles is that > the simple and most common use cases should be the simplest for the > user to code. Yes. OpenSSL is an infamous example of design failure in this respect. However, the term "software design principle" is a bit vague. More specifically you're identifying a maxim of good programming interface design. What's good for a library API is not necessarily what's good for a system call interface. System calls are not really library functions, and that is why they have had a different section in the manual from day one. open/reda/write/(l)seek/close did not primarily constitute, as I think they were originally conceived, and API; they were there to expose _primitives_ of the operating system. The lateness in coming of the C standard I/O library may have been something of a problem here; an I/O library is exactly where you want to press your design principle to the maximum. (On the other hand, sometimes the design space needs to be explored, and you don't know what the common cases are going to be because you don't have enough data points yet. In that case you expose the primitive operations and study what bubbles up when programmers apply the DRY principle--they are future standard library calls in disguise.) But I suspect another problem, even had stdio.h been around in 1972, would have been the obsessive false economy of "programming close to the metal". Because the C language did that, and because the system call interface was there and easy to grab a hold of, tons of application programmers thought they should follow suit, violating Knuth's principle about optimization with fervor. > I've always thought that the UNIX file primitives very elegantly > adhere to this principle. Reading a file in UNIX is a simple > open()/read().../close() sequence. Contrast that with VMS's $QIO or > IBM OS access methods, where the full complexity is not only exposed > in the interface, it must be considered, set up, and controlled by the > user for even the simplest operations. Multibuffered, asynchronous, > interrupt-driven I/O is more complicated (if not downright clumsy) in > UNIX than in VMS or OS/VS, but that's OK, IMO--it shifts the > complexity burden to those doing complex things. I haven't programmed on VMS or OS/VS, but again this sounds like a scenario where a standard I/O library should have existed but didn't (or was inadequate to the demands placed on it--as stdio itself arguably still is, with a static global errno variable and an original design that ignored reentrancy entirely, such that we have to consult manuals to determine which calls are safe for multi-threaded apps or use in a signal handler). Context has to be managed somewhere. open()/read()/.../close() only look simple because a lot of context has been pushed down into the kernel--the list of flags supported by open() has steadily grown over the years. The POSIX openat() system call family is a superior design, though still saddled with a lot of context. I admit, it is probably more annoying to use for application programmers who want to use it directly. That's because they're trying to solve their problems at the wrong level. It irritates them that they have to keep track of their own contexts (in this case, a file descriptor). A well-designed library is able to do this for them, but they want to be close to the metal. And too many of them will not do the job adequately themselves, so they demand that the kernel handle it itself. Now the system call interface is even less a set of primitives, and even more something that's "easy to code to" for sloppy programmers. That is one way kernel interfaces, memory requirements, and task-switching times bloat. How close to the metal does one feel then? --=20 Regards, Branden --dfychyqzfwqjlg4p Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAlvaFzoACgkQ0Z6cfXEm bc6zhg/8DP0SN54TB+I5Sj5/1MBHkLDHW398AtXeg861G9oSLKA/RLhdjNqpdZmE WDFaTxyNfpUCjI+4gkY30AgMMOlB1QfN/hs2pmIseCoS9CcXBPN/SKBxNjGF400r XULO6wvg2U5OZhezBMvMV3G/3Nc96z/VyDS/gEjLhWGokAVe95e4/YB/SdNYF0Z4 szlJpUyyXqHntX34TrtWRhDja2qvKXJo/g46sslIB+mgODh2J4trhWJF2t5xay8l g2IfW8nlTSoGRI4kmv2ftUWOs2yVjKdrZyMa0a0JwHIPGvoekAecNDV03K3RlzgQ 1k+14KugYi7fC2+LKW4QBNs0K4PHtp+SYL+ttiOZ0Z7Frh2Ino7+6mebnRMmqH2h KZLUZUTG0x2MYoCyxed2k7+sx+puj+f/qvc42uHPXl4TNlpJBXIiNRJnJzlQ8VSo 1YBUHZv6Bj90JsHXGeFo875eFMgCCCQehh9dprfwv6LZFV+Etc//z7lAdKZQtj0q xy8bsIxRwArxTO4Awo8kBKGg2xcg6yP5ZScP0tngIBA3V8w711Y9zPnXFIfcs+VA Ku3VsqyrLSumt9Haf98rvjtV3y5S3BVXtHXzhz02UCHBLxqlk09q6k4OLbazBkRa V7BUkwmD3G8DKbgfggmBSq/6H7P7YEkNEzJ0sJLTedO9b6FFmtc= =6IAZ -----END PGP SIGNATURE----- --dfychyqzfwqjlg4p--