streams/ioctls

Guy Harris guy at auspex.auspex.com
Sat Jan 5 06:45:36 AEST 1991


(My goodness, a "comp.unix.internals" posting that discusses, well, UNIX
internals!  What will they think of next?)

> ttys in sysVr[34] seem to be implemented using streams.

S5R4, yes.  S5R3, not in general.

>I_STR seems to be the only ioctl which is passed to modules/drivers.

No, most "ioctl"s are passed on; the problem is that, unless the code
that implements "ioctl()" (the stream head code, not the module/driver
code) knows how much data is to be copied in or out by the "ioctl()", it
can't attach it to an M_IOCTL message being sent downstream. 

> Apparently in sunos4.x the ioctl call will convert "normal" ioctls
> (ie, defined with IO, IOR, etc) into I_STR's, when applied to a stream.

That's one way of putting it, I guess.  I'd say rather that, as you
note, the BSD-style "ioctl" cookies used by SunOS include the number of
bytes of data to be copied, so it can copy the data in and attach it to
the M_IOCTL message; it's not really a matter of "converting" it to an
I_STR.

> So, what do sysVr[34] do?  Does ioctl "know" about all of the
> termio ioctls (ie, size and direction) and convert them to I_STR's?

S5R3's stream head code does, in fact, know about some "ioctl"s, and
copies the data in (or attaches the argument as a message, for calls
such as TCFLSH).  S5R4's may do the same, but there are also the
"copyin" and "copyout" messages that the other poster noted.



More information about the Comp.unix.internals mailing list