STREAMS tty drivers for SysV

Guy Harris guy at auspex.auspex.com
Tue Jun 13 04:56:21 AEST 1989


>It is impossible to put a SVID-compliant tty under the SVR3.[012] stream head
>as it comes on the 3B2 source tapes.  There is no provision for VTIM/VMIN in
>the SVR3 streams head, and you cannot do it below the head in SVR3 streams.
>Also, the SVR3 stream head believes a non-blocking read returns EAGAIN like
>BSD ttys and other, reasonable SV devices, instead of 0 like SVID tty's.
>
>Sun may have an advantage or two.  Did they put a BSD "new tty" style driver
>under their streams, instead of something current-SVID-compliant?

No, Sun put a System V-style driver - SVID-compliant - under a stream
head that had, as you guessed, been modified to:

	1) support VMIN/VTIME;

	2) support BSD-style non-blocking I/O (using EWOULDBLOCK), and
	   an S5-style non-blocking I/O that permits a streams module
	   (such as "ldterm", the tty driver module) to say that it
	   wants tty-style non-blocking I/O (return 0) rather than the
	   default streams-style non-blocking I/O (return -1 and set
	   "errno" to EAGAIN);

and then put another streams module under it to translate some of the
old BSD-style functions into new-style functions (the SV-style driver
supports additional flag bits to give you BSD-style user interface
goodies, and also directly supports some BSD-style "ioctl"s - some of
which I expect to be in S5R4, such as TIOC[SG]PGRP, TIOC[GS]WINSZ,
TIOCMGET/TIOCMSET/etc.).

>They might reasonably expect someone to listen to their requests to
>change the next version of the SVID.

I expect some of the BSD functions to be in S5R4, and possibly the SVID.
I expect VMIN/VTIME to be unchanged, though, from previous editions of
the SVID (other than, perhaps, POSIX changes - but I think POSIX
specifies the same thing as the SVID).

>They may also have modified the stream head.

They did.  I expect S5R4 to have changes to the stream head that will
enable it to support VMIN/VTIME, but I don't expect them to be the same
as Sun's.  I also expect it to have changes to permit it to support
"old-style" non-blocking I/O, as well as POSIX-style non-blocking I/O
(which is pretty much the same as the "new-style" non-blocking I/O as is
supported by the S5R3 streams head - they use different flag names, so
old code will continue to work in source and binary form, and new code
can use O_NONBLOCK to get new-style non-blocking I/O even on ttys).



More information about the Comp.unix.wizards mailing list