is this wise?

[Leslie Mikesell]

In article <9321 at alice.UUCP> dmr at alice.UUCP writes:
>
>Nevertheless, the idea could probably be pushed through.
>(Indeed, as someone pointed out, it was done in Chaosnet.)
>In particular, Rick Adams's reductions to absurdity are
>quite close to things that the Plan 9 system (as opposed to
>Ninth Edition) actually does; as many of its abstractions
>as possible are mapped into the file system.

It makes sense to me.  Shouldn't the abstraction of relating a process
request to an OS resource be generalized as much as possible (and
we obviously already need open(), read(), write())?  Didn't someone
mention replacing gettimeofday() with open("/dev/clock")?  Consider
the advantage of being able to provide a single time source to a
network with a symlink instead of recompiling everything with the
gettimeofday() library routine.
What is needed to make this work (and worthwhile in its own right)
is a "parallel" fd that can be used for control requests.  That is,
read() or write() to that fd would do the things currently done via
fcntl() and ioctl().  This could be done in a text format, thus
converting the device-specific ioctl structs into something that we
already have to deal with: text lines of variable length.  This would
provide at once (a) the ability to fully control devices and file
locking from shell scripts or any language that knows read() and
write() - the device specific items can be read from a text file as
needed and (b) the ability to control devices over an network in a
machine-independent format since we already have the ability to write
character arrays among machines which would eliminate the problem with
ioctl() over RFS.
The obvious choice for the "parallel" fd would be -fd, but the
existence of fd 0 and the overloading of the "-" character on
command lines rules this out, so I suppose it would be fd|MAGIC_COOKIE.

Les Mikesell