Very Computer

Quote:> Haven't seen the book you cite anywhere. All the bookstores around here
> have the SVID-based one only.

Well, that's too bad, but the book *you* cite appears to be the only book that
claims to be a System V manual (as opposed to a System V interface definition)
and that has this layout.  In other words, the book you cite is an exception to
the rule, and complaints about its contents cannot validly be extended to
complaints about System V documentation in general.

Quote:> I wish it was. Unfortunately the book I cite is the only one I've seen,
> and it's also the one Microport is distributing as their UNIX manual.

It's not the one AT&T is distributing as *its* UNIX manual, nor is it, I
suspect, what most vendors distribute.

Quote:> I didn't say it was in section 2 or section 3. I said it was in BA_SYS...

I quote here from your original article:

Quote:> Except that the O/S *manuals* follow the SVID. And except that it confuses
> people. "Hey, peter, how come they have read and fread?" "Well, fread is
> a library routine." "Oh. How do you tell which ones are library routines?"
> "read the manual. Library routines are section 3" "section 3? I don't
> have a section 3" "What? Let me look at that... they must be kidding".

I see nothing about BA_SYS here.  I see only a claim that "the O/S manuals
follow the SVID", which is NOT true in general; it is only true for that one
anomalous manual you saw.  All the System V manuals we've gotten from AT&T have
the traditional division between sections 2 and 3.

Quote:> > Remember, we're NOT just talking about "traditional UNIX systems" here.
> > This "read" could be implemented atop a non-UNIX system, or a UNIX system
> > with more general facilities for sharing than "traditional" systems.

> Since the title of the message is "System V manuals", don't you think we
> should be talking about System V?

Well, first of all, if we're talking about System V, we should talk about it in
comp.unix.questions, so this discussion is moving there.

Second of all, in the claim you made said nothing about implementing "read"
under a vanilla System V system.  You just said

Quote:> I don't believe you could implement "read" as a library routine and retain
> the attribute of leaving the file descriptor at the point last read, unless
> you were to "implement" it by making a direct call to the existing read
> routine. Certainly buffering would be out.

with no such qualification.  You could definitely do this under some
non-vanilla implementations, e.g. Apollo's DOMAIN/IX.

For that matter, you could probably do it under vanilla System V, if the IPC
code, including shared memory, is configured into the kernel.  You may not
*want* to do it that way, but it's not impossible.

The fact that it *doesn't* happen to be implemented that way in most UNIX
systems is irrelevant; you didn't say it *wasn't* done that way, you said that
you didn't believe it *could* be done that way.
        Guy Harris
        {ihnp4, decvax, seismo, decwrl, ...}!sun!guy

Quote:> > Why does the SVID stick read() and fread() in the same place?

> I don't know about your system, but on mine you need to supply
> an int to read and a pointer to type FILE [ FILE *fn etc]

Which doesn't answer the question.  I have no idea why they were stuck in the
same place; it certainly doesn't reflect the way this stuff is actually
packaged.  If there is some notion that the stuff in BA_OS should represent
"system calls" (whatever that means - on *some* systems it means "routines
consisting of a tiny wrapper around a trap", but not on others), "fread" - and
"fopen", which is also in BA_OS - certainly doesn't belong there; I know of no
UNIX implementations where "fopen" and/or "fread" are just simple traps.

Quote:> The difference is that read() and its brethren use file
> to do all there opperations while fread() and it's brethren use
> streams.

> Apearently every stream has at least one file handle assoicated with it
> but the level and method that streams interact with the kernel
> are quite different than simple files.  That is "any Transport
> Level Interface" [network, etc.] MUST be a stream when you open
> it.  If you want to then use read() against it you must manually
> push a streams-module that will properly react to the read()
> calls.

Unfortunately, the word "stream" is vastly overused when discussing computer
systems, and in particular when discussing UNIX systems.  "stream" is used to
refer to the object that a standard I/O "FILE *" refers to; it is also used to
refer to the object to which a UNIX file descriptor created by opening a
STREAMS device refers.  The two meanings have little to do with one another.  A
standard I/O "stream" can have as its file descriptor a STREAMS "stream", but
it need not, nor need you wrap a standard I/O "stream" around a UNIX "stream".

Quote:> I guess what I am trying to say is that, on my system of corse,
> read() and fread() have a different scope.  It is therefore
> approprate that they are listed as read(2) and fread(3S).
> If your system is not "UNIX" read may end up as a library
> refrence, but if it is a library on you computer I don't
> think it's standard.  On the other hand, an "fread" type
> of system-call-primitive is NECESSARY to interact with the
> streams modules in the kernel.  Since SVID includes streams
> definitions, I would assume that fread(2) will soon be the
> new standard, hence SVID may well say read(2) and fread(2)
> [or however they are designating these things].

"fread" has nothing to do with STREAMS (although, if you have a standard I/O
"stream" that refers to a STREAMS device, you can do an "fread" on a STREAMS
"stream"), and it is not a "system-call-primitive".  STREAMS "streams" are
referred to by file descriptors of the same sort as the file descriptors that
refer to regular files, and you can use the same "read" and "write" system
calls on file descriptors referring to STREAMS "streams" as you can on file
descriptors referring to plain files.  As such, "fread" will not "soon be the
new standard", and certainly won't replace "read".
        Guy Harris
        {ihnp4, decvax, seismo, decwrl, ...}!sun!guy

(Quoting an earlier article):

Quote:>> > Why does the SVID stick read() and fread() in the same place?

>  I have no idea why they were stuck in the
>same place; it certainly doesn't reflect the way this stuff is actually
>packaged.  If there is some notion that the stuff in BA_OS should represent
>"system calls" (whatever that means - on *some* systems it means "routines
>consisting of a tiny wrapper around a trap", but not on others), "fread" - and
>"fopen", which is also in BA_OS - certainly doesn't belong there;

To quote from SVID, v1, section 3.1, which lists BA_OS routines:
  "Table 3-1 lists the Operating System Service Routines whose run-time
   behaviour must be supported by any implementation of the Base System"

Both read(2) and fread(3) are in the list [1].  Note the SVID does not mention
any distinction between the UNIX manual chapter 2 and chapter 3 routines;
which is where is implementation dependent;  what is required is that the
semantics of the call are supported.  The programmer does not need to be
concerned with chapter 2 / chapter 3 dichotomies unless efficiency is a
paramount concern; and then portability would be ignored anyway.

Note also that FREAD(BA_OS) is in the first set of routines on the list,
which "... should fulfill the needs of most application-programs," and
READ(BA_OS) is in the second set, which "should be used by application-
programs only when some special need requires it."

I don't read the SVID as requiring any routine to be a "trap" vs a
"system call."  In fact, there could conceivably be implementations
fully SVID conformant with NO traps, just real live subroutine calls
with the traps buried fairly deeply.  Think about hosted systems,
for example.

[1] More properly and pedantically, routines with calling semantics
identical to read in chapter 2 of the UNIX Programmer's Manual and
fread of chapter 3.  

                mike

                                  ...!seismo!decuac!csmunix!icase!msf
These are my opinions and not necessarily official views of any
organization.

Apparently I needed to use upper case.  On my system "STREAMS" are not
defined when compared with read() in many cases [most spesifically
network "STREAMS" module(s)] The fact that you "can do fread on a
"STREAMS" stream" was quite my point.

Quote:> and it is not a "system-call-primitive".

Also, quite my point.  It is not NOW a system call primitive, it
is a library routine, thats why I SAID FREAD(3S)!.

Quote:> STREAMS "streams" are
> referred to by file descriptors of the same sort as the file descriptors that
> refer to regular files,

It is therefore strange that my programmers refrence refers to a
function:

int fileno(stream)
FILE *stream;

under FERROR(3S) which: "returns the interger file descriptor associated
with the named _stream_<italics<; see _open(2)_<italics<.
 NOTE: Only GOD knows why they put it under FERROR(3S) but _they_
obviously wanted to make the distinction.

Quote:> and you can use the same "read" and "write" system
> calls on file descriptors referring to STREAMS "streams" as you can on file
> descriptors referring to plain files.

I have been given to beleive that this is not the case.  The C
use of read() on "STREAMS" such as standard input _BYPASSES_ the
STREAMS module and drivers and gets the file handle from the
lib, and uses it on the file directly.  The same holds true
for "normal" files.  If you use this on a STREAMS-only device
the bypassing of the stream device lets you read the transport
provider [in the case of networks] directly, dropping you two
or more layers in the 7-layer model.  if you want to read() the
data you need to tpush() the approprate emulator on the
STREAMS-head.  If you don't, you get trash, and if you do, you
are locked out of most of the STREAMS functions until you tpop()
the module off.  [For more information, get a book on using
the Transport Level Interface]
NOTE: when you use a _multiplexing_ stream head to deal with
iregular input from multiple sources as if it were a single
source, I havn't got the foggiest what read() does.

Quote:> As such, "fread" will not "soon be the
> new standard", and certainly won't replace "read".

FORTUNATELY <sp?> THIS IS _NOT_ WHAT I SAID.... WHERE DID YOU
GET _"replace"_ ??????????!

I SAID: <paraphrased> that finding read(2) AND fread(2)
may soon be the new standard.

YOU WILL PLEASE NOTE THE _AND_, "2"s, AND THE LACK OF A PERIOD, OR OTHER
DISTURBING PUNCTUATION IN THAT SENTENCE.  YOUR "ORIGINAL" RESTATED
QUESTION WAS "why are read() and fread() in the same place?" (in
SVID)  THIS IS THE QUESTION I ANSWERED HERE, AS SUPPOSITION, NO LESS.
If you are using vnews, I seguest you use "p" once or twice and read
the paragraph again.

IN THE FUTURE I WOULD APPRICIATE IT IF YOU WOULD DO THE FOLLOWING:
        1) ONLY QUOTE ME IN CONTEXT.
        2) READ BEFORE YOU FLAME.
        3) CHECK YOU MANUAL FOR _REFRENCES_ BEFORE YOU FLAME
        4) STOP TAKING EVERYTHING SO PERSONAL.

Rob.

p.s.  To anybody my previous posting confused, aparently I SHOULD
have used the uppercase when writing "streams".  If it's that
important, just read every occurance of "streams" as "STREAMS"

Quote:> I don't read the SVID as requiring any routine to be a "trap" vs a
> "system call."

Neither do I, which is why I merely said that BA_OS routines would be wrappers
around traps only on some systems.
        Guy Harris
        {ihnp4, decvax, seismo, decwrl, ...}!sun!guy

Quote:> Apparently I needed to use upper case.  On my system "STREAMS" are not
> defined when compared with read() in many cases [most spesifically
> network "STREAMS" module(s)] The fact that you "can do fread on a
> "STREAMS" stream" was quite my point.

> > and it is not a "system-call-primitive".

> Also, quite my point.  It is not NOW a system call primitive, it
> is a library routine, thats why I SAID FREAD(3S)!.

No, what you said was:

Quote:> On the other hand, an "fread" type of system-call-primitive is NECESSARY
> to interact with the streams modules in the kernel.

which is complete rubbish.  Prior to that, you said:

Quote:> The difference is that read() and its brethren use file
> to do all there opperations while fread() and it's brethren use
> streams.
> Apearently every stream has at least one file handle assoicated with it
> but the level and method that streams interact with the kernel
> are quite different than simple files.  That is "any Transport
> Level Interface" [network, etc.] MUST be a stream when you open
> it.  If you want to then use read() against it you must manually
> push a streams-module that will properly react to the read()
> calls.

from which it is extremely clear that when you said "streams" you meant
"streams" as supported by the STREAMS mechanism.  However, you do not need to
use this non-existent "fread" "system-call-primitive" to read from a "stream"
as supported by the STREAMS mechanism; "read" will do quite well.

Quote:> It is therefore strange that my programmers refrence refers to a
> function:

> int fileno(stream)
> FILE *stream;

> under FERROR(3S) which: "returns the interger file descriptor associated
> with the named _stream_<italics<; see _open(2)_<italics<.

Yes, but that refers to a standard I/O stream, not a STREAMS stream.  The two
*are* different.

Quote:> > and you can use the same "read" and "write" system
> > calls on file descriptors referring to STREAMS "streams" as you can on file
> > descriptors referring to plain files.

> I have been given to beleive that this is not the case.  The C
> use of read() on "STREAMS" such as standard input _BYPASSES_ the
> STREAMS module and drivers and gets the file handle from the
> lib, and uses it on the file directly.  The same holds true
> for "normal" files.

What?  This is complete rubbish.  I don't know who got you to believe that, but
if that's what they really said I'd suggest you not believe them in the future.
If they *didn't* really say that, I suggest you learn enough about UNIX and the
STREAMS mechanism to be able to understand what they say in the future.

You CAN NOT "bypass the STREAMS module and driver" by using "read".  "read"
bypasses any *standard I/O buffering* that would be done by e.g. "fread";
however, this has nothing whatsoever to do with STREAMS modules or drivers.

Quote:> If you use this on a STREAMS-only device the bypassing of the stream device
> lets you read the transport provider [in the case of networks] directly,
> dropping you two or more layers in the 7-layer model.

What?  STREAMS modules tend to go up to the transport layer (or maybe the
session layer); other layers are generally implemented in user mode.

Quote:> if you want to read() the data you need to tpush() the approprate emulator
> on the STREAMS-head.

This is ONLY true if you're using the TLI interface.  STREAMS is a *general*
mechanism that can be used for things having nothing to do with networking; you
could, for example, have a STREAMS-based tty driver, in which case you'd damn
well better be able to do regular "read"s and "write"s!

Quote:> NOTE: when you use a _multiplexing_ stream head to deal with
> iregular input from multiple sources as if it were a single
> source, I havn't got the foggiest what read() does.

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?

Quote:> YOUR "ORIGINAL" RESTATED QUESTION WAS "why are read() and fread() in the
> same place?" (in SVID)  THIS IS THE QUESTION I ANSWERED HERE, AS
> SUPPOSITION, NO LESS.  If you are using vnews, I seguest you use "p" once
> or twice and read the paragraph again.

That wasn't *my* question.  That was somebody else's question.  If *you* are
using "vnews", I suggest you use "p" once or twice and read the articles again.

Quote:> p.s.  To anybody my previous posting confused, aparently I SHOULD
> have used the uppercase when writing "streams".  If it's that
> important, just read every occurance of "streams" as "STREAMS"

After performing this transformation, one gets:

Quote:> It is therefore strange that my programmers refrence refers to a
> function:
> int fileno(stream)
> FILE *stream;
> under FERROR(3S) which: "returns the interger file descriptor associated
> with the named STREAM<italics<...

which would imply that "fileno" is here dealing with STREAMS.  It is not; this
is complete rubbish.

It appears that the problem here is that you *still* haven't figured out is
that when discusing standard I/O, and when discussing STREAMS, the term
"stream" is used; however, they do not mean the same thing.
        Guy Harris
        {ihnp4, decvax, seismo, decwrl, ...}!sun!guy

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

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.

Quote:> > 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?
> [user process]
>    |
> [Multiplexor Driver]
>           |   |   |
> module:   A   B & C

> etc. ad nasuim.

For some reason, probably to simplify the diagram, they omitted the stream head
from this diagram.  It's still there; it's *always* there in *any* stream.

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

Nope.  "poll" is just 4.2BSD's "select" with a propellor beanie.  It has
nothing to do with STREAMS multiplexor drivers; it is used for "multiplexing",
in a sense.  It is used if a program wants to manage several streams,
"multiplexing", if you will, its time between servicing those streams.

"poll" is given a set of cookies, each one of which expresses interest in the
state of various file descriptors that refer to streams.  The caller of "poll"
can ask whether a "read" or "getmsg" can be done on the stream without blocking
(i.e., data is present at the stream head); whether a "write" or "putmsg" can
be done on the stream without blocking (i.e., there is not so much data queued
somewhere that flow control would cause a "write" or "putmsg" to block); or
whether a high-priority message is present at the stream head.  (These provide
basically the same functionality as the "read", "write", and "exceptional
condition" bit masks for the "select" system call.)

It blocks until at least one of the streams referred to is in the state or
states for which interest has been expressed for that stream.  It will also
return if one of the streams gets an error or hangup message.

Programs that use "poll" (or "select") are often written as a big loop with a
"poll" at the top.  If the "poll" returns, it means that some amount of I/O can
be done on some subset of the streams in question without blocking.  It does
whatever I/O it can, and returns to the top of the loop.  The program will
typically put descriptors on which "write"s or "putmsg"s are to be done in
non-blocking mode, so that you can attempt to write as much data as possible,
and the system will only write as much data as can be written without blocking
and tell you how much that was.  This is often a good idea for streams on which
"read"s or "getmsg"s are to be done, as well, since "poll" (or "select") can
return because there is data to be read, but the data could be flushed (due
e.g. to an M_FLUSH message going upstream) before the "read" is actually done.
        Guy Harris
        {ihnp4, decvax, seismo, decwrl, ...}!sun!guy

The impression the entire text [Deleted for brevity :-)] gave was that the
"multiplexor driver" was the head of a stream [perhaps "special" in
some way] into which connections to the heads of other STREAMS could be
pushed [or ioctl(ed) in some way. i.e.:

"Upper multiplexors are a spesific application of standard STREAMS
facilities that support multiple minor devices in a device driver."

Im begining to get the feeling that this STREAMS primer should be used
for "Priming" bonfires.  This thing is full of mixed messages.

Would it therefore be more correct to have something like:

Process       A           B           C          D
              |           |           |          |
Head         (a)         (b)         (c)        (d)
              |           |           |          |
        [               Upper Multiplexor               ]
                                |
                                |
        [               Lower Multiplexor               ]
                |               |               |       ]
Device          1               2               3

Or is the entire thing even more convoluted???

Rob.