Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.internals
Subject: Re: streams/ioctls
Message-ID: <5031@auspex.auspex.com>
Date: 4 Jan 91 19:45:36 GMT
References: <25370@adm.brl.mil>
Organization: Auspex Systems, Santa Clara
Lines: 30

(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.