Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.26/text0048.txt

Text File | 1992-02-21 | 4.6 KB | 92 lines

Submitted-by: [e-mail] (Dan Bernstein)

Jason Zions writes:
> There is an expectation that one can open() a local
> file, a remote file, a real-time message queue, a secure file, and a named
> network connection, all with a function whose name is open() and has some
> common parameters.

*Why*?

Many people share this ``expectation.'' I don't understand why. Is it
because of ``the UNIX philosophy''? Or because a super-open() is
supposed to be easier for programmers? Or for users?

Let me dispose of these myths, one by one. First of all, ``the UNIX
philosophy'' is not ``everything's a file.'' Nor is it ``everything
has a name in the filesystem.'' It never was. In v7, pipes were not
files. Pipes still aren't files. Streams and sockets aren't in the
filesystem either.

The UNIX philosophy is that everything is a *file descriptor*. This is
why pipes are so useful---programs are written to use the *file
descriptors* 0, 1, and 2. File descriptors---and, most importantly, the
way that descriptors are inherited across fork() and exec()---are the
whole reason that tools work together better in UNIX than in any other
operating system. Input and output---read() and write()---work on file
descriptors uniformly. That's why tools work the same way whether
they're talking to a tty, a file, a pipe, a socket, or what have you.
*That's* the UNIX philosophy.

The UNIX philosophy doesn't give a damn how many syscalls there are to
create descriptors in the first place---as long as they all work with
read(), write(), dup(), close(), fork(), exec(), and so on. If it's so
important for UNIX that there be a single syscall to create new file
descriptors, how come v7 had *three* syscalls---not just open(), but
also pipe() and creat()? If you want to get rid of socket(), accept(),
socketpair(), connect(), and any other non-open() way of creating a
descriptor, all in the name of ``the UNIX philosophy,'' then why don't
you include pipe() in your super-open() too?

Let's move on to the supposed simplicity of super-open() for programmers.
Since when was it difficult to create, e.g., network connections with the
BSD syscalls? You can take any program you want---any program which uses
*file descriptors*, that is---and offer it as a service under inetd. Or
use any number of available packages (example: my clientserver package)
which let you do the same thing from shell scripts or inside programs.
Once you have a single utility which opens a network connection and passes
the *file descriptor* to the program of your choice, you can forget about
the details of network code and simply stick to read() and write(). Why
would a super-complex super-open() be any easier than this?

Or to take your example of ``a secure file''---there's a utility running
around which implements access control lists on any UNIX system. It works
the same way as the network utilities: it does the appropriate checks,
creates the *file descriptor*, and passes it to any program you specify.
There you have it: ACLs without super-open() and without any kernel mods!
Is it really supposed to be simpler to have even more flags and arguments
to open()?

Competent UNIX programmers write tools which stick to stdin, stdout, and
stderr. Only a few specialized tools---cat, sh, inetd---have to worry
about open() or pipe() or socket(). By adding a super-open() you might
make it a tiny bit easier to write those specialized tools, but you're
also bloating the kernel for something which the vast majority of
programs will never use. Why do you think the market hasn't even
considered a similar syscall?

Finally, let's consider super-open()'s advantages for users. Certainly
it'd be nice for a user to be able to type something like, say,

   % cat #[e-mail]

(disclaimer: I haven't given any thought to a good notation for this)
and have cat read from a TCP socket connected to port 13 on athena. Does
this mean that open() should support such notation? No! By kludging that
into the kernel you're taking control away from the user. The UNIX way
is much better for all concerned: *Let the shell worry about it*. Let the
shell parse #[e-mail] and invoke the right programs to set up a
network connection. Give users the freedom to choose shells which offer
the notations they like. Should I point out that several existing shells,
ksh for example, already provide such constructs?

``There is an expectation that one can open() a local file, a remote
file, a real-time message queue, a secure file, and a named network
connection, all with a function whose name is open() and has some common
parameters.'' Once again I ask: Why?

---Dan

Volume-Number: Volume 26, Number 50