In article <199601132306.RAA14250@solutions.solon.com>,
Peter Seebach  <seebs@solon.com> wrote:
> >> Oh, and lots of new ioctl() to handle the "other stuff".
> 
> >No, as someone else already said, just open the ctl file and read/write
> >it.  The only excuse for ioctl is code that needs to do things when
> >handed just a file descriptor, like stdio doing a TCGETA on stdout.
> >I'm not sure how to address that.
> 
> Simple.  Open /dev/fd/n/ctl, where n is the file descriptor.

I think this is going too far. While I admire Plan 9's effort to
reinstate the "single namespace" concept that made Unix beautiful, I
think this is wrong. 

The problem, IMHO, is not the exactly the existance of ioctl().  It's
that read/write/seek/etc is an arbitraty and limited set of methods for
manipulating the objects in the namespace; The fact that ioctl() is
needed shows that the set of methods is too limited.  Changing the
interface for ioctls (which is really all you're talking about... it's
still an ioctl) doesn't solve that wart. I think your solution is
worse, in fact, since it requires you to manipulate a second object to
do operations on the first.  A somewhat cleaner solution than ioctl()
would be OOB data writes to perform control operations, if you want to
limit things strictly to read/write/seek.

This is kind of beyond the realm of NetBSD, though. NetBSD is a
"modern UNIX", for better or worse, and works reasonably well in that
role. Trying to stretch things too far isn't worth it. If you want
to radically change semantics, you're better off writing an OS from
scratch, or playing with something a little closer to what you want
(VSTa, maybe).

-- 
Ty Sarna                "[Arafat] is just a good actress"
tsarna@endicor.com        - A palastinian interviewed on CNN-HN 12/15/95