Re: Virtual serial ports
Re: Virtual serial ports
- Subject: Re: Virtual serial ports
- From: Régis Duchesne <email@hidden>
- Date: Thu, 13 Sep 2007 10:39:02 -0700
Terry Lambert wrote:
> This is probably about a 70 line program, if you include signal handling
> and EOF processing,
>
> Then you can use the slave sides as if they were com ports from both ends.
>
> If you need pseudo CTS/RTS/DTR/DSR/BRK signal processing, you will need
> to get fancier,
It is quite tricky to implement proper virtual serial port over PTYs. I
did it for VMware.
The transmission of UART break state (used by lots of debuggers) and
errors is non-trivial: you must program the PTY so that it puts these
events as escaped codes in the data stream. Then you need a state
machine to unescape them.
Also, a communication between 2 real UARTs is lossy: if one UART sends
16 (UART FIFO size) + 1 bytes, and nobody listen at the receiving side,
1 byte will be lost by the receiving side. PTYs are (unfortunately in
this case) lossless (just like pipe), and thus the 70 line program you
are talking about must simulate this ability to "drop" bytes. Debuggers
rely on that too, especially when trying to connect to their target.
And I'm not even talking about flow-control yet :)
> The interesting driver (which has to be done in kernel space) is a
> device driver that looks like a serial port to a vmware client, and
> looks like a serial port to the host OS on the other end. That lets
> you do serial gdb from the host OS to your victim (Julian Elischer
> wrote one of these for FreeBSD at one point in time). Effectively,
> that gets you two machine debugging on one machine.
If you don't feel like writing this driver, you can use 2 VMware VMs
(one runs the debugger, one runs the target).
--
hpreg
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden