home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / programm / 3988 < prev    next >
Encoding:
Internet Message Format  |  1992-07-29  |  3.6 KB
  1. Xref: sparky comp.unix.programmer:3988 comp.unix.wizards:3345 comp.unix.internals:1628
  2. Newsgroups: comp.unix.programmer,comp.unix.wizards,comp.unix.internals
  3. Path: sparky!uunet!psgrain!hippo!ucthpx!aim1!aim1!gram
  4. From: gram@aim1.aztec.co.za (Graham Wheeler)
  5. Subject: STREAMS help desperately needed
  6. Message-ID: <gram.712407467@aim1>
  7. Organization: Aztec Information Management
  8. Date: Wed, 29 Jul 1992 10:57:47 GMT
  9. Lines: 92
  10.  
  11. No-one has responded to my previous posts about the ldterm STREAMS module, so
  12. I have resigned myself to having to handle all the termio ioctls myself. 
  13. Unfortunately, things haven't got any better. The first ioctl that getty is
  14. issuing to my module is a TCGETA. I am trying to handle this in as sensible
  15. a way as I can (given the lousy documentation), and my machine now just
  16. hangs up completely.
  17.  
  18. Here is what the manual (UNIX System V Release 4 Programmer's Guide: STREAMS)
  19. says:
  20.  
  21. pg 7-13: The TCGETA call, if formed as an I_STR call with a data buffer pointer
  22.     set to a value by the user, will always have a data buffer attached to
  23.     b_cont from the main message block. If one assumes that the data block
  24.     is not there and allocates a new buffer and assigned b_cont to point
  25.     at it, the original buffer will be lost. Thus, before assuming that the
  26.     ioctl message does not have a buffer attached, one should check first.
  27.  
  28. pg B-5: If a module processing an I_STR ioctl wants to send data to a user 
  29.     process, it must use the M_IOCACK message which it constructs such that
  30.     the M_IOCACK block is linked to one or more following M_DATA blocks
  31.     containing the user data. The module must set ioc_count to the number
  32.     of data bytes sent...
  33.  
  34. Here is my code (with lots of debuggery in):
  35.  
  36. static int PADuwput(queue_t *q, mblk_t *mp) {
  37.     struct PAD *PAD;
  38.     struct termio *tp;
  39.     PAD = (struct PAD *) q->q_ptr;
  40.     switch (mp->b_datap->db_type) {
  41.     ...
  42.     case M_IOCTL: {
  43.         ...
  44.         case TCGETA:
  45.             PADdebug(2,iocp->ioc_count==TRANSPARENT?
  46.                     "Got transparent TCGETA ioctl\n":
  47.                     "Got TCGETA ioctl\n");
  48.             dumpMessage(mp);
  49.             /* It turns out it is not transparent, but an I_STR
  50.                 ioctl, so... */
  51.  
  52.             cmn_err(CE_CONT,"Non-transparent, ioc_count=%d\n",iocp->ioc_count);
  53.             if (mp->b_cont==NULL) {
  54.                 cmn_err(CE_CONT,"Allocating termio buffer\n");
  55.                 mp->b_cont = allocb(sizeof(struct termio),BPRI_HI);
  56.                 iocp->ioc_count += sizeof(struct termio);
  57.                 mp->b_cont->b_wptr = mp->b_cont->b_rptr+sizeof(struct termio);
  58.             }
  59.             tp = (struct termio *)mp->b_cont->b_datap;
  60.             tp->c_iflag = PAD->terminfo.c_iflag;
  61.             tp->c_oflag = PAD->terminfo.c_oflag;
  62.             tp->c_lflag = PAD->terminfo.c_lflag;
  63.             cmn_err(CE_CONT,"ACKing IOCTL\n");
  64.             mp->b_datap->db_type = M_IOCACK;
  65.             qreply(q,mp);
  66.             break;
  67.         .....
  68.         }
  69.         .....
  70.     }
  71.     cmn_err(CE_CONT,"Finished in PADuwput\n");
  72.     return 0;
  73. }
  74.  
  75. ============
  76. The output I get is:
  77.  
  78. got TCGETA ioctl
  79. Non-transparent, ioc_count=0
  80. Allocating termio buffer
  81. ACKing IOCTL
  82. Finished in PADuwput
  83.  
  84. After which the machine dies (very quietly).
  85.  
  86. I am at a loss as to what to do next (other than writing my own getty!) I find
  87. it strange that getty does not give me a termio buffer in the first place,
  88. and even stranger that the whole OS dies as a consequence of this code.
  89.  
  90. PLEASE someone, save me from the depths of despair! Or I'll end up reverting
  91. to writing `Goodbye cruel world' C programs (I certainly won't have a job
  92. anymore).
  93.  
  94. Yours in desperation
  95. G.
  96.  
  97.  
  98. -- 
  99. Graham Wheeler                     | "That which is weak conquers the strong,
  100. Software Systems Engineer/Student  | that which is soft conquers the hard."
  101. Aztec Information Management/UCT   |         Lao Tzu - Tao Te Ching Ch. 78
  102. gram@aim1.aztec.co.za / gram@cs.uct.ac.za 
  103.