Standards Update, Recent Standards Activities
Henry Spencer
henry at zoo.toronto.edu
Wed Jul 4 08:43:54 AEST 1990
From: henry at zoo.toronto.edu (Henry Spencer)
>From: Jason Zions <jason at cnd.hp.com>
>How about because it constrains implementations to make DNI
>kernel-resident?
Nonsense. Nothing in 1003.n constrains implementations to make anything
kernel-resident. Things like read() are functions, which may or may not
reflect the primitives of the underlying kernel. They are merely required
to communicate -- somehow -- with something that performs the required
services.
Why have two different kinds of endpoints for I/O? We already have one
which is general enough to encompass almost every kind of I/O under the sun.
>How about because the semantics of operations permitted on POSIX file
>descriptors are a poor match for many transport providers? Read()/write()
>are stream operations; only TCP is a stream transport provider. OSI TP0/2/4
>maps much more closely to stdio and fgets()/fputs() in that it is
>record-oriented. What does it mean to seek() on a network endpoint?
Read()/write() are stream operations that work perfectly well as record
operations too. As witness Unix ttys, which are record-oriented devices
on input, and Unix magtapes, which are record-oriented both ways. As for
what it means to seek on a network endpoint, exactly the same as it means
to seek on a tty: probably nothing. But why invent new mechanisms for
I/O when the old ones will do perfectly well?
"Don't fix it if it ain't broken."
Henry Spencer at U of Toronto Zoology
henry at zoo.toronto.edu utzoo!henry
Volume-Number: Volume 20, Number 93
More information about the Comp.std.unix
mailing list