SysV.4 Streams and Modules programming problem: 1

SysV.4 Streams and Modules programming problem: 1

Post by Nick Levert » Sat, 25 Sep 1993 12:03:42

I have a problem with Streams, as follows. I'm working on a SysV.4
system which, if I interpret the release numbers right, is ICL's
version 6 level 3 of AT&T i386 V.4.0 release 3.0.

There exists on this system an old executable program which is
hard-coded for a particular terminal type. I'm writing a front end for
it which will interpret the screen codes and, using Curses, translate
them to work on other video types.

My program works by creating a pipe and forking/execvping the old
program. One end of the pipe is the program's stdin/stdout. The other
end is read/written in my program. This all works fine for ordinary
screen/keyboard data.

I need to catch the program's IOCTLs in order to know when it wants me
to echo keyboard input and when I mustn't. I read up on Streams and
modules and thought I could do it by creating a pipe like this:

   myprog <--> pckt <--> ptem <--> ldterm <--> ttycompat <--> oldprog

I do it as follows: after I fork the child but before I exec, I push
ptem, ldterm and ttycompat onto its end of the pipe, then dup it to
stdin and stdout. After I fork the parent, I push pckt onto *its* end.

The parent reads with getmsg() and I expect the control portion of
returned messages to be M_DATA or M_IOCTL. But I only ever see M_DATA,
except for one final ioctl when the pipe is being closed. If I replace
'oldprog' by a shell script which contains stty commands, then I *do*
see M_IOCTLs for it.

I have also tried pushing 'pipemod' both before pushing pckt and before
ptem. The manual was most unclear on whether this was Essential,
Optional or a Bad Idea. But it didn't make any difference, anyway :-(

It may or may not be relevant that there seems to be a timing problem.
The child starts writing to stdout before the parent has pushed pckt. I
tried avoiding this by doing all the pushed before the fork, but it
appears that pushed modules are not inherited by the child. I don't
really want to use a semaphore, but I fear it may be unavoidable.

It's more likely, though, that I've misinterpretted the manual. I'd
really appreciate any help. I'm the only person I know who's gone into
Streams at this depth and I'm having to learn to swim real fast :-) All
suggestions, either for the Streams problem or for better ways of doing
it, gratefully welcomed.

Many thanks

Nick Leverton
"Politician! Where's your credibility ?
You promised to lay down your life to set your people free"  -  Hugh Masekela.


1. SysV.4 Streams and Modules programming problem: 2

To help with the problem I detailed in my previous post, I wanted to
trace inter-module messages. Now, I have typed in (sans printing errors)
and installed the 'dump' module from the STREAMS Programmer's Reference.

But I can't make it work properly. When inbetween two other modules, it
seems to work. But when adjacent to the stream head, any application
write(2) returns zero and no data is written. This means I don't get a
full trace of what's going through the pipe.

Is there something special that a Streams module has to do to accept a
message from a stream head ? All I can think of is that the dump module
has no service routine. However I had to guess somewhat for installing
it, as the manual refers to /etc/master.d as a configuration file. I
have only /etc/conf/cf.d/mdevice, /etc/conf/pack.d/Driver.o and

Again, many thanks for any help.

Nick Leverton
Lies, damned lies and user documentation.

2. Linux 2.5.23-ct1

3. SysV.4 Streams and Modules programming problem: 1

4. Problem with lseek and read

5. stream module programming problem...

6. PLEASE HELP to setup Linux on my second HD

7. ppp/slip for solaris 2.2 ?

8. What happens if a stream module is pushed onto multiple stream driver?

9. Solaris x86 failure to push streams module into network stream

10. How to push STREAMS module into socket stream

11. SysV Streams & Linux

12. Streams and Critical Regions on SYSV 4.0