stanonik@nprdc.navy.mil (Ron Stanonik) (01/03/91)
ttys in sysVr[34] seem to be implemented using streams. I_STR seems to be the only ioctl which is passed to modules/drivers. How then do the termio ioctls affect modules/drivers? 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. (The "streams module and driver programming" tutorial seems to say this in the "driver and module ioctls" section.) Apparently this can happen because in sunos the macros for defining ioctls (eg, IO, IOR, etc) include the size and direction of the ioctl. In sysVr[34] ioctls don't seem to include the size and direction (ie, ioctls seem to be defined using only the type and command, TCGETA == 't'<<8|1). 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? Thanks, Ron Stanonik stanonik@nprdc.navy.mil
ws@tools.uucp (Wolfgang Solfrank) (01/03/91)
I don't know about V.3 (maybe ttys are implemented as traditional character devices with line discipline?), but in V.4 there are additional messages available that the driver/module can send to the streams head to get data from the application or put data there. So the scenario is: ioctl gets converted to message and sent downstream module/driver sends message upstream requesting any data stream head sends data to module/driver module/driver performs ioctl module/driver sends message upstream containing data stream head puts data into app and sends ack module/driver acknowledges ioctl Of course one or the other of the data transfer messages may be skipped. This processing also supports ioctls that contain addresses of other data structures in their parameter. Normally the second transfer message could be substituted by including the response data in the ioctl ack. Hope this helps... -- ws@tools.uucp (Wolfgang Solfrank, TooLs GmbH) +49-228-230088
guy@auspex.auspex.com (Guy Harris) (01/05/91)
(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.