ske@pkmab.se (Kristoffer Eriksson) (04/26/89)
In article <10089@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > In article <13589@ncoast.ORG> allbery@ncoast.UUCP (Brandon S. Allbery) writes: > >I think it's safe to assume that Streams now passes random ioctls(). > > The fundamental problem is that ioctls typically have associated data > structures, and if their format is unknown (as would be the case for > ioctls unknown to the local system), there is no way to ensure that > the data would not be mangled by the time it reached a remote system's > ioctl handlers. How about inventing "ioctl converters"? The ioctl data would pass through one converter at the local host, and another one at the remote host. The converters would convert to and from some standard data representation, like XDR. Each converter has information about all standard ioctl data formats on it's own host, through some sort of configuration, and can comunicate that information to the other converter when needed. This is transparent to old applications. Additional non-standard ioctl formats used by new programs, can be dynamically registered at the local converter by the programs that implement those ioctls. It would be difficult to have one converter only, just at one of the hosts, since such a converter would have to be able to convert to and from any conceivable data format, and there would have to be some protocol to describe any conceivable data format to the converter (any byte or bit order, any word sizes, any structure member alignment). With two converters, each one just has to understand the local data formats and the common one. When communicating between two processes on the same host, this sheme would suffer no overhead at all, since there would be no converters involved. Of course, there's still the problem of the same ioctl function on different hosts using different request codes (2:nd argument), especially if any program is able to invent new ones. Maybe a simpler solution is to let each network define a common (for all hosts on that net) set and coding of standard ioctls, that the networking interfaces must implement, and just let any program that uses non-standard ioctls do all conversions by itself. Why worry about compatibility, for something that is non-standard anyway? (Maybe that is exactly what SVR4 is going to do? I don't now anything about that.) BTW, when I think of it, the Unix V.2 system (well, it has a couple of non-standard additions, V.3 is expected RSN) I am using right now, does it's networking in a user process, and there is a file /usr/lib/net/ioctltab, that seems to describe the request number and data format of about 90 ioctls that somehow can be forwarded through the network. Naturally, that works only between hosts with this special brand of Unix. Ioctls that are not mentioned in this file, can not be handled. The mechanism that lets a process running in user space do the networking, in place of the kernel, is called "request queues". I think they are somewhat similar to streams, but I don't know much of the details of either of them. Anyway, this was implemented a couple of years before streams were released. A process can "mount" itself on any directory, and through the request queue it is informed of all file operations other processes request on files imagined in the mounted directory. I've always wondered why something like that (but a little bit better yet) wasn't introduced into general Unix long ago. Maybe the time is coming. > The whole ioctl scheme needs rethinking for > heterogeneous networked environments. Sure does! > I suspect SVR4 will use something > like XDR for passing ioctls over stream connections, but that doesn't > really solve the problem. All the really good solutions I've been able > to think of are fundamentally incompatible with existing practice. Tell us about the "really good solutions." Maybe I've totally missed the point in my ramblings above... -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske