is this wise?

[Steve Summit]

In article <378 at chessene.UUCP> root at chessene.UUCP (Mark Buda) writes:
>Consider this (and ignore the lack of error checking):
>/* finger.c */
>f = fopen("/dev/hosts/uunet.uu.net/tcp/79", "r+");

Shades of CHAOSnet.  (Is it still around?)

On a CHAOSnet system (I am not making this up), this would have
been something like*

	open("/dev/chc0/remotehost/fingerd", 0)

This required modifications to namei, to be sure, but less
sweeping than you might think, because /dev/chc0 (or whatever it
was called) was, if memory serves, a character-special directory
file (i.e. st_mode&S_IFMT was S_IFDIR|S_IFCHR).  Sublime and/or
ridiculous, but a "neat hack" all the same.

The server end of the Unix CHAOSnet implementation was nice, as
well; much closer (IMHO) to the "Unix Philosophy" than the
current jangled mess**.  Continuing with the above example, the
chaosnet listener daemon on machine "remotehost" would simply
exec /usr/lib/chaos/fingerd, with standard input and output
connected to the network stream.  Notice that services were
essentially named with names, not numbers; no /etc/services lists
and funny magic socket numbers were required.  If you wanted to
add a new service, all you had to do was stick it in your
/usr/lib/chaos directory and tell people about it; they could
"open" it right away.  (The daemons were generally simple to
write, as well.  "fingerd" could just be /bin/who, for instance.)

Accessing network services in this way is an overloading of the
open call, to be sure, but overloading is not necessarily a Bad
Thing.  The consensus seems to be that /dev/fd and /dev/proc, for
instance, are the cat's meow.  (I suspect that a remotehost and
service syntax built into a pathname could be implemented without
change to namei on a system with a file system switch or other
mechanism that makes things like /dev/proc possible.)

					     Steve Summit
					     scs at adam.pika.mit.edu

* The names "/dev/chc0" and "fingerd" are incorrect; it's been a
  long time and I can't remember what they really were.

** Okay, maybe not "jangled mess;" I guess the welter of daemons,
   one per service, most unused at any given time and
   accomplishing nothing except occupying process table slots and
   keeping swap space warm, has been more recently replaced with
   a single master daemon, which is a step in the right
   direction, but it still seems like there's a lot more hair
   than there has to be, and that the kernel is involved in too
   much of it.