🚀 go-pugleaf

From:  Jason Zions <jason@cnd.hp.com>

Regarding the Snitch Editor's fine report, in the section discussing
1003.12 comes the following sentence:

> Our snitch, Andy Nicholson, challenged readers to find a reason not to
> make DNI endpoints POSIX file descriptors, but has seen no takers.

How about because it constrains implementations to make DNI
kernel-resident?

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?

A significant branch of the UNIX(tm)-system and POSIX research community
believes "All the world's a file"; the Research Unix V.8 and Plan 9 folks
are among the leaders here. I feel only slightly squeemish about accusing
them of having only a hammer in their toolbelt; of *course* everything
looks like a nail!

I think it would probably be acceptable to have a DNI function which
accepted a DNI endpoint as argument and attempted to return a real file
descriptor. This function would check to see that the underlying transport
provider could present reasonable semantics through a POSIX file
descriptor, and would also check that the implementation supported access
to that transport provider through a kernel interface.

Jason Zions

*  UNIX is a trademark of AT&T in the US and other countries.
** Obstreperous iconoclast is a behavioral trademark of Jason Zions in the
   US and other countries.

Volume-Number: Volume 20, Number 85