gwyn@smoke.BRL.MIL (Doug Gwyn) (04/27/89)
In article <976@pkmab.se> ske@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.