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,HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1661 invoked from network); 24 Jun 2020 15:22:38 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 24 Jun 2020 15:22:38 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 33C06945A2; Thu, 25 Jun 2020 01:22:36 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 258B59459A; Thu, 25 Jun 2020 01:22:12 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="KggOBB3V"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 815B09459A; Thu, 25 Jun 2020 01:22:09 +1000 (AEST) Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) by minnie.tuhs.org (Postfix) with ESMTPS id BE0AE94599 for ; Thu, 25 Jun 2020 01:22:08 +1000 (AEST) Received: by mail-qv1-f43.google.com with SMTP id dp10so1190692qvb.10 for ; Wed, 24 Jun 2020 08:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6zrQ+sMn0r3A+aq4Byoee681knPmYtEYZFip0RbKpKU=; b=KggOBB3VL3O/WwF7gSwlt6CCrZjSUegYM6XCwuxrDN5L70GV7Cc3vvoo6qQ5M5P2gl T8/934lECVKU/iGj3PW36FwbYHXwDykEMTAXyCRqAAg7I/u6T4sKmcRxk8SfgTgjLvdi 9NFoazDbMJuBzdWZhZVaVEU5pUfMtOu8S668U= 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=6zrQ+sMn0r3A+aq4Byoee681knPmYtEYZFip0RbKpKU=; b=eptTb+FMR5inRLhWp7X1Heqk6Hbbs8Ck4WxX7RdmQWpQ4TMmoZypjmX25oXd5RxO6i Ht4+4KvCzdZvjcnq5hVJEQ7MiXMCtkHofeIXQxSeqDVRkxvBiYF8mWETtAuz77l4A+lF TD7S6aQICB3TvMEFcwSLSVHbWrRxVQGVTI0WAwV5u812smQ7dS7tzJnuVqZ1dOBRoDyD Bd/nhuWrmMWhiGK9hAe+S2HxJEuxCpFvmSZwpVhDSkcRMYCWDAPwHQwfHFBArYzIInOL bSGPlNsPBJAhWCCxRMhQKfMSw9kokBarYPsWPGL+upThXXOiTrqFWlvm3oQmRnLcAVD+ BB2w== X-Gm-Message-State: AOAM5315RPSDrNdrl/vi5zGlrY1X61B2TD5oKifg7z55tkuj4TcsGuVF pKsnnHAFU6m9TBtj0cLLJI3d5+2Go0y0hLRY4eJnhArCjFA= X-Google-Smtp-Source: ABdhPJwukR0FhlkLI6Neflg+ckdwsXMzgH9XOVZnOfoekOY5MgVzbqPHsVGInBK7AC17/MTPYZEZlQeyfJGqYcV+uuE= X-Received: by 2002:a0c:e4d3:: with SMTP id g19mr32147035qvm.42.1593012127595; Wed, 24 Jun 2020 08:22:07 -0700 (PDT) MIME-Version: 1.0 References: <20200624143129.1913318C0BD@mercury.lcs.mit.edu> In-Reply-To: <20200624143129.1913318C0BD@mercury.lcs.mit.edu> From: Clem Cole Date: Wed, 24 Jun 2020 11:21:41 -0400 Message-ID: To: Noel Chiappa Content-Type: multipart/alternative; boundary="000000000000fd133f05a8d609b8" 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: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000fd133f05a8d609b8 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 24, 2020 at 10:32 AM Noel Chiappa wrote: > > From: Dave Horsfall > > > Ioctl: the Swiss Army knife of system calls. I thought it was a neat > > idea when it arrived (much better then those primitive stty/gtty > calls) > > but now... > > Like they say, when the only tool you have is a hammer... > > Better syntax than stty/gtty, maybe but I'm not sure the semantics are that > much better. The problem is that, especially with devices, what the I/O > commands do is so widely varied that it's hard to fit them all under a > unified umbrella. Maybe some (e.g. asynchronous I/O), but not all. > I remember the change from stty/gtty which was peculiar to tty's in v6 to ioctl in v7 and thinking it was a nice clean generalization. Then I realized it had at least two big issues -- no concept of direction nor the size of the container being moved. So, then I see it start to get abused and I said -- oh my -- that was clearly not well thought out. Plan 9's solution of the CTL file with an ASCII interface, I thought was cleaner. IIRC TRIX had a controller interface too, but I've forgotten the details now. Here is the problem.... if you make everything a byte stream (which is a great fundamental way of building up a small cooperating program with a common interface), how do you handle the mechanisms to modify the stream in a manner than make sense (control if you will) in an out-of-band manner, but not end up with a fisherman's stew of different and special things (access methods, frameworks, *et al*) that are peculiar to that specific stream? The problem with stty/getty was is was specific to TTY's. It was a fine OOB scheme, but did not make sense for say changing parameters on other devices (tape as an example). The tape solution was different names, which worked there because you were not supposed to change things like density mid tape write. Other peripherals worked differently. ioctl became the only way out, as Noel points out. So ... this begs the question? Does the ctl file idea work better than ioctl? You still have to know what the ctl interface is for that device? It is ASCII which is nice and huge improvement over the binary command encoding crap. Clem --000000000000fd133f05a8d609b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 24, 2020 at 10:3= 2 AM Noel Chiappa <jnc@mercur= y.lcs.mit.edu> wrote:
=C2=A0 =C2=A0 > From: Dave Horsfall <dave@horsfall.org>

=C2=A0 =C2=A0 > Ioctl: the Swiss Army knife of system calls.=C2=A0 I tho= ught it was a neat
=C2=A0 =C2=A0 > idea when it arrived (much better then those primitive s= tty/gtty calls)
=C2=A0 =C2=A0 > but now...

Like they say, when the only tool you have is a hammer...

Better syntax than stty/gtty, maybe but I'm not sure the semantics are = that
much better. The problem is that, especially with devices, what the I/O
commands do is so widely varied that it's hard to fit them all under a<= br> unified umbrella. Maybe some (e.g. asynchronous I/O), but not all.
I remember the change from stty/gtty which was peculiar to= tty's in v6 to ioctl in v7 and thinking it was a nice clean generaliza= tion. Then I realized it had at least two big issues -- no concept of direc= tion nor the size of the container being moved.=C2=A0 =C2=A0So, then I see = it=C2=A0start to get abused and I said -- oh my -- that was clearly not wel= l thought out.=C2=A0 =C2=A0Plan 9's solution of the CTL file with an AS= CII interface, I thought was cleaner.=C2=A0 =C2=A0IIRC TRIX had a controlle= r interface too, but I've forgotten the details now.=C2=A0
=

Here is the problem....=C2=A0 =C2=A0if you make ever= ything a byte stream (which is a great fundamental=C2=A0way of building up = a small cooperating=C2=A0program with a common interface), how do you handl= e the mechanisms to modify the stream in a manner than make sense (control = if you will) in an out-of-band manner, but not end up with a fisherman'= s stew of different and special things (access methods, frameworks, et a= l) that are peculiar to that specific stream?=C2=A0 =C2=A0=C2=A0
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">
The problem with stty/getty was is was specific to TTY's= .=C2=A0 It was a fine OOB scheme, but did not make sense for say changing p= arameters=C2=A0on other devices (tape as an example).=C2=A0 =C2=A0The tape = solution was different names, which worked there because you were not suppo= sed to change things like density mid tape write.=C2=A0 Other peripherals w= orked differently.=C2=A0 =C2=A0ioctl became the only way out, as Noel point= s out.

So ...=C2=A0this begs the question?=C2=A0 Does = the ctl file idea work better than ioctl?=C2=A0 =C2=A0You still have to kno= w what the ctl interface is for that device?=C2=A0 =C2=A0It is ASCII which = is nice and huge improvement over the binary command encoding crap.

Clem

--000000000000fd133f05a8d609b8--