Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!oliveb!sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: comp.unix.questions Subject: Re: System V manuals (was Re: What real non-UNIX 'C' compilers...) Message-ID: <31154@sun.uucp> Date: Fri, 16-Oct-87 22:09:21 EDT Article-I.D.: sun.31154 Posted: Fri Oct 16 22:09:21 1987 Date-Received: Sun, 18-Oct-87 08:32:45 EDT References: <855@sugar.UUCP> <29930@sun.uucp> <867@sugar.UUCP> <30458@sun.uucp> <133@nusdhub.UUCP> Sender: news@sun.uucp Lines: 121 > 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: > 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: > 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. > 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_ > 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. > 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. > 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! > 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? > 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. > 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: > 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