Path: utzoo!attcan!uunet!husc6!mailrus!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: BSD:sockets::SVID:(what?)
Message-ID: <58773@sun.uucp>
Date: 2 Jul 88 00:50:26 GMT
References: <5968@umn-cs.cs.umn.edu> <2820@ttidca.TTI.COM> <8207@brl-smoke.ARPA>
Sender: news@sun.uucp
Lines: 29

> The funny thing is, the original comment was that STREAMS had to be
> changed to accommodate features of the BERKELEY terminal handler.
> It now sounds like it had to be changed for System V itself.

It had to be changed for both.  It needed to be changed to support System V
VMIN/VTIME processing, of course (it's hard for a streams module to implement
VMIN = 0, VTIME != 0, since the timer starts when the "read" is done and
streams modules don't get told when somebody does a "read"), but it also had to
be modified for:

	1) job control

and

	2) some backwards compatibility stuff (support for TIOCGETD and
	   TIOCSETD, which have to be mapped in a somewhat unpleasant fashion
	   into pushes and pops of streams modules)

which could be counted as features of the Berkeley terminal handler.  (The S5
driver has line disciplines as well; however, since the only one provided with
vanilla S5 was the standard one, we didn't bother making "c_line" do anything
in the S5-style "ioctl"s.)

In addition, it had to be changed to support "select" (building "select" on top
of "poll" turns out to be uglier than just implementing "select" for streams,
given the way "poll" is implemented), as well as BSD-style no-delay I/O and
"asynchronous" I/O.  (It also had to be changed for S5-style no-delay I/O,
because streams no-delay I/O is basically POSIX-style non-blocking I/O, which
resembles BSD-style no-delay I/O.)