Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!sun!decwrl!labrea!jade!ucbvax!sdcsvax!ucsdhub!jack!man!nusdhub!rwhite
From: rwhite@nusdhub.UUCP (Robert C. White Jr.)
Newsgroups: comp.unix.questions
Subject: Re: System V manuals (was Re: What real non-UNIX 'C' compilers...)
Message-ID: <139@nusdhub.UUCP>
Date: Sat, 17-Oct-87 19:00:06 EDT
Article-I.D.: nusdhub.139
Posted: Sat Oct 17 19:00:06 1987
Date-Received: Sun, 18-Oct-87 22:42:43 EDT
References: <855@sugar.UUCP> <29930@sun.uucp> <867@sugar.UUCP> <30458@sun.uucp> <31154@sun.uucp>
Organization: National University, San Diego
Lines: 80
Summary: Everything but:

I will for the most par assume that everything you have told me is correct,
but as far as this:

In article <31154@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes:
> It reads whatever data is at the stream had for the stream that refers to the
> multiplexor (there is no such thing as a "multiplexing stream head";
> multiplexors are drivers at the bottom of the stream).  What did you *think* it
> did?

BULL $#!+

And I quote: [UNIX System V Streams Primer pp 6-7]

	STREAMS multiplexing supports teh development of internetworking
protocols such as IP and ISO CLNS, and the processing of interleaved data
streams such as in SNA, X.25, and Terminal window facilities.

	STREAMS multiplexors (also called psudo-device drivers) are created
in the kernel by interconnecting multiple Streams.  Conceptually, there are
two kinds of multiplexors that developers can build with STREAMS: upper
and lower multiplexors.  Lower multiplexors have multiple lower Streams
between device drivers and the multiplexor, and upper multiplexors have
upper Streams between user processes the multiplexor.

[BAD GRAMMER IN THE LAST SENTENCE IS A DIRECT QUOTE]

This is then followed by a diagram which has the basic form:

[user process]
	|
[Multiplexor Driver]
          |   |   |
module:   A   B & C

etc. ad nasuim.

It goes on to talk about using a single multiplexing stream head to
control different modules with ioctl() and the like, followed by
the quote:

"The Facility allows users to set up the inter-module/driver plumbing to
create multiplexor configurations of generally unlimited interconnection."

Perhaps multiplexing is why ther is a poll() system call.
If the multiplexing were only at the bottom, what would this be for?

In the other issues I must say you get better marks than I.  I found
the miss refrenced passage about read and write.

[pp 7-1]

DRIVERS:

	At the interface to hardware devices, character I/O drivers have
interrupt entry points; at the system interface, those same drivers generally
have direct entry points (routines) to process open, close, read, write and
ioctl system calls.

	STREAMS device drivers have similar interrupt entry points at the
hardware device interface and have direct entry points only for open and
close system calls.  These entry points are accessed vi STREAMS, and the 
call formats differ from character device drivers.  The put procedure is a
drivers third entry point, but it is a message (not system) interface.  The
Stream head translates write and ioctl calls into messages and sends them
downstream to be processed by the driver's write QUEUE put procedure.
read is seen directly only by the Stream head, which contains functions
required to process system calls. [etc.]

- - - - - - - 

What this means is that my read and fread coments were someware in the
neighbor hood of "COMPLEETLY WRONG".  I had thought that when you
pushed the module on the stream, it became the new "head"  This
snoballed into a total mis-understanding on my part, and hence the
previousley posted bullshit.

SO how about this: I'm partly right, your mostly right, and neither of
	us will take it personally.

Rob.