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

[Chip Salzenberg]

Submitted-by: chip at tct.uucp (Chip Salzenberg)

According to ok at goanna.cs.rmit.OZ.AU (Richard A. O'Keefe):
>My program *can't* know what's available.  If someone comes along
>with a special "open hyperspace shunt" function; my program can't
>benefit from it.  If hyperspace shunts are in the global name space
>and posix_open() understands their name syntax, my program will work
>just fine.

Thank you, Richard, for stating well what I have intuitively felt.

(Dan, you wanted a reasoned rebuttal.  Very well: here it is.)

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.  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.

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.

One could argue that binary-only distribution is evil and should be
stopped.  I can agree that binaries are less useful than source code;
in fact, my personal motto is, "Unless you have source code, it isn't
software."  Nevertheless, copyright and trade secret law being what
they are, we will continue to see binary-only distributions for the
indefinite future.

Even if source code were for all UNIX programs were freely available,
I doubt that anyone would seriously propose modifying *all* of them
each time a new kind of fd-accessible object were added to the kernel.

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.

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.
-- 
Chip Salzenberg at Teltronics/TCT     <chip at tct.uucp>, <uunet!pdn!tct!chip>
    "I've been cranky ever since my comp.unix.wizards was removed
         by that evil Chip Salzenberg."   -- John F. Haugh II


Volume-Number: Volume 21, Number 194