network ioctls (was: Ioctl and pipes)

[Doug Gwyn]

In article <976 at pkmab.se> ske at pkmab.se (Kristoffer Eriksson) writes:
>Tell us about the "really good solutions." Maybe I've totally missed the
>point in my ramblings above...

No, your "ramblings" were fine, and are probably in line with what
people are actually implementing for this.  There are problems with
some existing ioctls (e.g. those that pass buffer pointers in the
struct pointed to by the third argument to ioctl()), but if the
"ioctl format description" is general enough they can probably be
solved.

I also take for granted that issues of maintaining state in the
remote driver and synchronizing with various caches can be resolved.

I think the real problem with ioctl is the notion that you're asking
for mysterious operations outside of any model to be performed by a
low-level driver.  (I assume it is already obvious that high-level
ioctl()s are a different matter that can be solved by creative use of
"streams".)  When described in such terms, it is apparent that there
is a fundamental lack of constraints on the ioctl facility, which is
what makes an elegant solution impossible.  What is needed is an
elegant model that encompasses what we really need for such services,
much as the UNIX file model has made possible unified treatment of
many common system services that would appear to be dissimilar.  In
fact I thought of a way to eliminate ioctl hooks altogether and rely
on the file read/write interface, which I mentioned to Dennis who is
likely to have better ideas about these things (and who probably has
more time to work on them).  However, my idea was inelegant, in my
opinion, and I'm hoping that some other solution will emerge, perhaps
from the Plan 9 effort (and perhaps not).  I don't think that forcing
the existing low-level ioctl hooks into a network context is the best
that is possible, and would urge people who are working in this area
to step back and think deeply about what constraints make sense.