Unified I/O namespace: what's the point?

[Dan Bernstein]

Submitted-by: brnstnd at kramden.acf.nyu.edu (Dan Bernstein)

I was not planning to post further on this topic, but Chip has provided
some good arguments that deserve a proper rebuttal.

In article <13392 at cs.utexas.edu> chip at tct.uucp (Chip Salzenberg) writes:
> It is true that interactive use of UNIX, especially by programmers,
> puts a lot of emphasis on the shell interface.  If such an environment
> were all there were to Unix, then Dan's fd-centric view of the world
> could possibly be useful.

The success of UNIX has proven how useful this ``fd-centric'' view is.

> To use Richard's example: when a hyperspace
> shunt became available, its use would require only a change to the
> shell source code and a recompilation.

You are making an unwarranted assumption here: that the shell *has* to
handle all types of fd creation. It's convenient, of course, but by no
means necessary. My TCP connectors, for example, are implemented outside
the shell.

> However, the reality of modern Unix use is something else entirely:
> pre-packaged utilities, usually available only as binaries, that for
> practical purposes *cannot* be changed or replaced.  In this
> environment, kernel features that require program customization are
> unwieldy at best, useless at worst.  As long as shells fall into this
> category -- "programs usually distributed as binaries" -- fd-centric
> UNIX will never be practical.

This is also unfounded. My TCP connectors provide a counterexample to
your hypothesis (that the shell must handle everything and hence be
recompiled) and your conclusion (that fd-centric UNIX doesn't work).
Any programming problem can be solved by adding a level of indirection.

> One could argue that binary-only distribution is evil and should be
> stopped.

I do, in fact, think exactly that. But I will not use it as a basis for
my arguments.

> Finally, filenames often are stored in places where no shell will ever
> see them, such as program-specific configuration files.  So in Dan's
> hypothetical fd-centric UNIX, we would have to either (1) pass such
> filenames to the shell for interpretation, thus incurring a possibly
> substantial performance hit; or (2) modify each program to understand
> all the names the shell would understand.  In my opinion, neither of
> these alternatives is viable.

On the contrary. syslog is a counterexample. While it is hardly as
modular as I would like, it shows that (0) an fd-centric model works;
(1) you do not need to invoke the shell or any other process, and you do
not need to incur a performance hit; (2) you do not need to modify each
program to understand everything that the syslogd program can. syslog
has proven quite viable.

Provided that there is a message-passing facility available, and
provided that it has sufficient power to pass file descriptors (which is
true both under BSD's UNIX-domain sockets and under System V's streams),
the syslog model will generalize to any I/O mechanism without loss of
efficiency. open() can always be replaced by a write() to the facility
followed by a file descriptor transfer. This is just as easy to do
outside the kernel as inside the kernel; therefore it should be outside.

> To summarize:
> A unified namespace has one great advantage: new types of objects are
> immediately available to all programs -- even the programs for which
> you do not have the means or the desire to modify and recompile.

To summarize: I believe I've provided counterexamples to each of your
arguments and conclusions, and so I continue to maintain that a unified
namespace is pointless. There is no need to recompile any programs just
to provide a new I/O mechanism.

A unified namespace has several great disadvantages: 1. It provides a
competing abstraction with file descriptors, hence adding complexity to
the kernel, and giving vendors two different outlets for extensions.
This will result in a confused system, where some features are available
only under one abstraction or the other. 2. It is not clear that all
sensible I/O objects will fit into one namespace. If the precedent of a
unified namespace is established now, I/O objects that don't fit will be
much harder to add later. 3. A unified namespace has not been tested on
a large scale in the real world, and hence is an inappropriate object of
standardization at this time.

---Dan


Volume-Number: Volume 21, Number 195