Ioctl and pipes (was: Detecting Pipe Using Bourne Shell)

[Kristoffer Eriksson]

In article <10089 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
> In article <13589 at ncoast.ORG> allbery at 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 at pkmab.se
Fax:   +46 19-11 51 03  !  or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske