Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!longway!std-unix From: henry@zoo.toronto.edu (Henry Spencer) Newsgroups: comp.std.unix Subject: Re: Standards Update, Recent Standards Activities Message-ID: <778@longway.TIC.COM> Date: 3 Jul 90 22:43:54 GMT References: <770@longway.TIC.COM> Sender: std-unix@longway.TIC.COM Reply-To: std-unix@uunet.uu.net Lines: 34 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: henry@zoo.toronto.edu (Henry Spencer) >From: Jason Zions >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@zoo.toronto.edu utzoo!henry Volume-Number: Volume 20, Number 93