About pty's
  -----------

  Books refs.:

W. Richard Stevens, Advanced programming in the UNIX environment, Addison-Wesley 1992, 
Ch. 19 pp. 631-657
M. Johnson, E. Troan, Linux Applicatin Development, Addison-Wesley 1998, Ch. 15.6 pp. 
308-317

  online:

    $ info libc

  and then C-s openpty
  or scroll down to meny "* Pseudo-Terminals::"

A pty is like a full-duplex pipe, which also looks like a serial port.
Please try out my little spy program (ftp://kalle.csb.ki.se/spy.tgz)

 xterm 1:

   $ spy /dev/ttyS1
   /dev/pts/10
   v0.38 Ready..
   ....

 xterm 2:

   $ cu -l /dev/pts/10  # use pty reported by spy above

 and talk with your modem, while the traffig will be logged in xterm 1.

Or ( this example was done with an earlier version of the program)
tty 1 and tty 3 talks with each other, and the traffic get logged on tty 2:

 tty 1:

    $ ./spy    # note you have to kill this from another tty
    /dev/pts/9
    asdkfjhasd
    in read: Input/output error
                               /dev/pts/9
    Terminated
    $
    
 tty2:
    
    $ ./spy /dev/pts/9
    /dev/pts/10
       9.02 1 bytes, 3 -> 4: >a<
       9.30 1 bytes, 3 -> 4: >s<
       9.53 1 bytes, 3 -> 4: >d<
       9.79 1 bytes, 3 -> 4: >f<
      10.03 1 bytes, 3 -> 4: >v<
      10.25 1 bytes, 3 -> 4: >z<
      10.52 1 bytes, 3 -> 4: >x<
      12.04 1 bytes, 3 -> 4: >\r<
      12.25 1 bytes, 3 -> 4: >\n<
      14.47 1 bytes, 4 -> 3: >a<
      14.69 1 bytes, 4 -> 3: >s<
      14.91 1 bytes, 4 -> 3: >d<
      15.07 1 bytes, 4 -> 3: >k<
      15.28 1 bytes, 4 -> 3: >f<
      15.29 1 bytes, 4 -> 3: >j<
      15.50 1 bytes, 4 -> 3: >h<
      15.59 1 bytes, 4 -> 3: >a<
      15.74 1 bytes, 4 -> 3: >s<
      15.91 1 bytes, 4 -> 3: >d<
      16.94 1 bytes, 4 -> 3: >\r<
      17.19 1 bytes, 4 -> 3: >\n<
      27.10 1 bytes, 4 -> 3: >\r<
      31.10 1 bytes, 4 -> 3: >`<
      31.38 1 bytes, 4 -> 3: >.<
      37.92 1 bytes, 4 -> 3: >\r<
    in read: Input/output error
    /dev/pts/10

    $ killall spy
    $
    
 tty3:
    
    $ cu -l /dev/pts/10
    Connected.
    asdfvzx
    ~,[Unrecognized.  Use ~~ to send ~]
    ~.
    Disconnected.
    $ 


Regards,
/Karl

-----------------------------------------------------------------------
Karl Hammar                    Asp� Data           [EMAIL PROTECTED]
Lilla Asp� 2340             +46  173 140 57                    Networks
S-742 94 �sthammar         +46  70 511 97 84                  Computers
Sweden                                                       Consulting
-----------------------------------------------------------------------


From: Kees Cook <[EMAIL PROTECTED]>
Subject: Re: TYPE_COMM not being used in the kernel source
Date: Sun, 6 Aug 2000 08:24:24 -0500

> On Sun, Aug 06, 2000 at 11:40:08AM +0200, Marc SCHAEFER wrote:
> > Well, I have developped a Linux (user-space) driver for the Able
> > Communications SCSI serial device (16-port), two years ago.
> > This was however done as a contract work with NDA. I can only tell
> > what could be obviously seen from installing the driver:
> >
> >    - it uses the SCSI generic driver
> >    - it uses ptys
> >
> > The Able device I developped for had 16 serial lines with full
> > flow control and modem signals.
> 
> Excellent.  That sounds like a very similar product.  I'm relatively
> familiar with the SCSI generic driver (well, version 1, anyway.  version 2
> is a giant improvement.)  I'm new to ptys, though.  I found 0 docs on it,
> though.  What I know about pty allocation I stole from pppd, and had
> confirmed from a few mailing lists.  Are there better docs?
> 
> > If you have the specification for the protocol for your device type,
> > it shouldn't be too difficult to do something similar. The most
> > complicated part is the RTS/CTS and various signal handling.
> 
> That is exactly what I don't know how to do right now.  :)  Is there a
> simple way to "trap" ioctls done against the slave pty?  Because as long
> as I can trap the various serial-port ioctls, I can pass them to the
> device.
> 
> > I sustain your proposition for the patch (I didn't look at it,
> > however).
> 
> Cool.  I didn't mention it in my original email (but it's obvious from
> looking at the patch) that it is against 2.4.0-test5.  Who handles patch
> approval for linux-scsi?
> 
> --  
> Cornelius "Kees" Cook                           [EMAIL PROTECTED]
> Sr. Systems Engineer              Counterpoint Networking, Inc.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Reply via email to