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.5 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,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 728b2a1d for ; Sun, 4 Nov 2018 18:02:32 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 92C93A21F6; Mon, 5 Nov 2018 04:02:31 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id E8F66A21D9; Mon, 5 Nov 2018 04:01:39 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 99D58A1FB3; Mon, 5 Nov 2018 03:06:54 +1000 (AEST) Received: from mail-it1-f170.google.com (mail-it1-f170.google.com [209.85.166.170]) by minnie.tuhs.org (Postfix) with ESMTPS id 8517BA1FA4 for ; Mon, 5 Nov 2018 03:06:48 +1000 (AEST) Received: by mail-it1-f170.google.com with SMTP id b7-v6so9552522itd.5 for ; Sun, 04 Nov 2018 09:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H/h62exKRb89WUgHs6xkSjOY43z9XfSNlumJhnqfZq4=; b=ZxrvpsYcdaR3SM5mbcGMav0rLW3SRZTpTvdIWn6msaIYN8+htfsgNjLrwhMviRS8WY nc8dTT+KmEP3lvsOhBfgYoF0YnQuS9FFPR1muc+a7aZEbHA8bCEws04n1KnuEF6+IbvL uIyDnovdt5IXl1ua1pPbzdVwvZOf5FaOkxY7XGAGZbzHF9nZuHBPlJfKO6e6WXO5y9Js 4Zm/14KqG0EzlbFykjNc1T9v0bWwq1i95LYEB/ffPbG0tzVZvabfMmBSLYE9qCwS+rqb SLz/tB/6JaQPISMFAwnsN66g/z4c50Vb/GkRFf/LUBi1APMrYtFOXEsP8rwsrUKj18QK UbLQ== 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; bh=H/h62exKRb89WUgHs6xkSjOY43z9XfSNlumJhnqfZq4=; b=fbuwIe30z5CmAVBNhzVzv12ir974j+Mq2mxD9HmJJHC5oW9Yh91bad6wLe2kUGSpM5 SBe8e3wKNICu6O4eGUgwzXKqIxabNysM6zA8mdAJjPfURmZOMdAZyZzRlYO11IJEndDC VuxjnfrDFZvYfmiY7h83A10Egv/56a5HHH7Q8JBYYGxNO1qeEgcgYjngPINHq5wSPZyI ukZWe0x4SL1S+HfngiGOS2FkTwnMzgNF/1lW3p1VaVOQfjthcJzUUuCr0s95zbbKxdSc h3I+MJfQhTms8ja/wruI4r9k9VQ553YARUS0wrAjcY/B9CWitmbH8gDyb6cTJ3vtj5SN ZLqw== X-Gm-Message-State: AGRZ1gL9Vrng2FNSObgHH6tsZjJD5j4cnqmKSvLolz7zK90ILlqGK3R+ 8qlELy60WxjKYKnzbIJMeLiyzxlyq0fZypZzTAwfbw== X-Google-Smtp-Source: AJdET5eoQRnG73D9dXMcwcM2Ary/mNZeIWtremuxMAigBQ1u5Dzj9iDQ2D6WMzCt0fhBP3p043FcXKZf6XKswXZV4Zg= X-Received: by 2002:a02:2708:: with SMTP id g8-v6mr17057903jaa.93.1541351207410; Sun, 04 Nov 2018 09:06:47 -0800 (PST) MIME-Version: 1.0 References: <20181031043810.GA10775@minnie.tuhs.org> <20181101074231.GA4844@vagabond> <9AD89116-0552-440F-A251-1E93AA150B93@eschatologist.net> In-Reply-To: From: Warner Losh Date: Sun, 4 Nov 2018 10:06:36 -0700 Message-ID: To: ron minnich Content-Type: multipart/alternative; boundary="0000000000003136310579d9cb62" 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: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000003136310579d9cb62 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 4, 2018 at 9:31 AM ron minnich wrote: > On Sun, Nov 4, 2018 at 4:00 AM Chris Hanson > wrote: > > > This was broken from the start though, and always really meant > everything looks like a file *descriptor*, not a path in the filesystem. > > OK, I only got into this game in 1976, and a lot had happened in Unix by > then, > and maybe you saw some earlier stuff. But certainly in 1976, as > compared to the other 4 PDP-11 operating systems I was using, > the fact that resources had names visible to every program was very > important to us. On the competitor systems the naming would be built > into individual programs, > e.g. PIP or (non-PDP11) the MPE fcopy program, one of the few programs > on that system where you could name, e.g., the tape drive on your > terminal. > > Being able to use a path name for resources was a very big deal for us > at the time. And we didn't say file descriptors, we said names. > > Hence, I rate your comment as "interesting if true" but I see no > evidence to support it. > It depends on what you did... Tapes were always special. You could access them via a named interface, but it was tricky. Tapes are stateful creatures, and some programs wanted stateful, others wanted stateless. So you got different devices to do different behavior. Easy to oops and use the rmt0 instead of the nrmt0 device. So while it was a file, it was a file that had odd state you didn't have disks. Serial ports were worse. There you had no way to control the serial port except with fancy extra programs. There was no /dev/ttyd0.9600.8N1 devnode to open. If you wanted 9600 baud, you had to either hack the driver to do that on open, or you had to hack your programs to know they were talking to a special thing and needed special code to cope (raw vs cooked was another one). so, sure, it was file based, but not entirely file based as you had to escape to either hacky system calls (v6 and earlier) or later generalized ioctls (v7 and later). Every other snowflake device had it's own config program that you had to run (or ioctls your data collection programs had to do). Setting up the sampling rates for the A2D, or the signal strength for an IRIG generator or whatever. So sure, you could address these devices by a file name, but you couldn't "cp config /dev/irig" or "cat /dev/ttyd0.2400.7O2" to get data flowing on the devices, so their addresses in the filesystem namespace were of limited value since some files were more special than others. I'm not sure plan-9 solved this by having a second device side-channel either in its attempt to try a different approach to side-channel communications than ioctl(2). Network sockets are a logical conclusion to this state of affairs, btw. All the plethera of new system calls for them could have been done as ioctls, though the generic processing stuff for ioctls would have gotten in the way of some of the socket API. It's another twist on the baud rate problem: I need to communicate metadata about how to do things to the driver... And in this case, a lot of the 'how to do things' is negotiated via a different side channel (routed, ARP, etc) and so you no longer had a raw physical network device to open, but a logical, cooked one that you interacted at the top of the stack to and all those other details were abstracted out / taken care of in other ways. It's unfortunate that you can't just open "/dev/net/sri-nic.arpa" and have it do the right thing, but files kinda want to be stateless and there's a lot of state about what you want to do with that open command... And while mounting allowed one to get files from a disk, it wasn't so good at doing things dynamically (as the original system were quite static) and required a number of ad-hoc hacks to make work right. block vs character devices showed early on a crack in the uniformity. So while I love the ideal, I also see how the practical side of things forced us down the path we're down, ugly warts and all. I'd love to see someone start with V7ish level of kernel, but add the modern things like devfs (so one could pass 'state' strings to drivers on 'open' and have them accept/reject them to get around some of these issues), as well as provide all objects in a namespace that's sane and mostly enumerable. For that you'd need new abstractions (like saying that all drivers don't interact via cdev-nodes like today, but instead present a filesystem-like interface so you'd open /dev/tty/d0/9600n1/hw-flow and the tty driver would get a message for its d0 instance of 9600n1/hw-flow, though this would break dirent(2)). In this world, you could have most of the crazy encoded into a path for network operations as well... though I have doubts you could do it in as a performant manner as sockets). Warner --0000000000003136310579d9cb62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun= , Nov 4, 2018 at 9:31 AM ron minnich <rminnich@gmail.com> wrote:
On Sun, Nov 4, 2018 at 4:00 AM Chris Hanson <cmhanson@eschatologist.net> = wrote:

> This was broken from the start though, and always really meant everyth= ing looks like a file *descriptor*, not a path in the filesystem.

OK, I only got into this game in 1976, and a lot had happened in Unix by th= en,
and maybe you saw some earlier stuff. But certainly in 1976, as
compared to the other 4 PDP-11 operating systems I was using,
the fact that resources had names visible to every program was very
important=C2=A0 to us. On the competitor systems the naming would be built<= br> into individual programs,
e.g. PIP or (non-PDP11) the MPE fcopy program, one of the few programs
on that system where you could name, e.g., the tape drive on your
terminal.

Being able to use a path name for resources was a very big deal for us
at the time. And we didn't say file descriptors, we said names.

Hence, I rate your comment as "interesting if true" but I see no<= br> evidence to support it.

It depends on w= hat you did...

Tapes were always special. You coul= d access them via a named interface, but it was tricky. Tapes are stateful = creatures, and some programs wanted stateful, others wanted stateless. So y= ou got different devices to do different behavior. Easy to oops and use the= rmt0 instead of the nrmt0 device. So while it was a file, it was a file th= at had odd state you didn't have disks.

Serial= ports were worse. There you had no way to control the serial port except w= ith fancy extra programs. There was no /dev/ttyd0.9600.8N1 devnode to open.= If you wanted 9600 baud, you had to either hack the driver to do that on o= pen, or you had to hack your programs to know they were talking to a specia= l thing and needed special code to cope (raw vs cooked was another one). so= , sure, it was file based, but not entirely file based as you had to escape= to either hacky system calls (v6 and earlier) or later generalized ioctls = (v7 and later).

Every other snowflake device had i= t's own config program that you had to run (or ioctls your data collect= ion programs had to do). Setting up the sampling rates for the A2D, or the = signal strength for an IRIG generator or whatever.

So sure, you could address these devices by a file name, but you couldn= 9;t "cp config /dev/irig" or "cat /dev/ttyd0.2400.7O2" = to get data flowing on the devices, so their addresses in the filesystem na= mespace were of limited value since some files were more special than other= s.

I'm not sure plan-9 solved this by having a= second device side-channel either in its attempt to try a different approa= ch to side-channel communications than ioctl(2).

N= etwork sockets are a logical conclusion to this state of affairs, btw. All = the plethera of new system calls for them could have been done as ioctls, t= hough the generic processing stuff for ioctls would have gotten in the way = of some of the socket API. It's another twist on the baud rate problem:= I need to communicate metadata about how to do things to the driver... And= in this case, a lot of the 'how to do things' is negotiated via a = different side channel (routed, ARP, etc) and so you no longer had a raw ph= ysical network device to open, but a logical, cooked one that you interacte= d at the top of the stack to and all those other details were abstracted ou= t / taken care of in other ways. It's unfortunate that you can't ju= st open "/dev/net/sri-nic.arpa" and have it do the right thing, b= ut files kinda want to be stateless and there's a lot of state about wh= at you want to do with that open command...

And wh= ile mounting allowed one to get files from a disk, it wasn't so good at= doing things dynamically (as the original system were quite static) and re= quired a number of ad-hoc hacks to make work right. block vs character devi= ces showed early on a crack in the uniformity.

So = while I love the ideal, I also see how the practical side of things forced = us down the path we're down, ugly warts and all. I'd love to see so= meone start with V7ish level of kernel, but add the modern things like devf= s (so one could pass 'state' strings to drivers on 'open' a= nd have them accept/reject them to get around some of these issues), as wel= l as provide all objects in a namespace that's sane and mostly enumerab= le. For that you'd need new abstractions (like saying that all drivers = don't interact via cdev-nodes like today, but instead present a filesys= tem-like interface so you'd open /dev/tty/d0/9600n1/hw-flow and the tty= driver would get a message for its d0 instance of 9600n1/hw-flow, though t= his would break dirent(2)). In this world, you could have most of the crazy= encoded into a path for network operations as well... though I have doubts= you could do it in as a performant manner as sockets).

Warner
--0000000000003136310579d9cb62--