Serial port conformance tests

[Chris Teague]

I'm new to wine, looking into serial communications.  I have a failing
scenario in a application, and I'd like to write a conformance test to
demonstrate/document the issue.  I looked in dlls/ntdll/tests but did
not see any serial port related tests - did I miss them or do none
exist yet?  Assuming none exist, a very useful tool would be a serial
port loopback device.  Rather than require conformance testers to
attach a hardware loopback device (NULL modem) to a physical port,
could we create some virtual ports in wine and connect them together?
Maybe com98 and com99 for example?  Anything written to one of the
ports would be sent to the other one.  On Windows this can be done
with a device driver, one example is com0com
(http://com0com.sourceforge.net/).
Is this a reasonable approach?  Thanks,
Chris

[Alexandre Julliard]

Chris Teague <chris.teague(a)gmail.com> writes:
> I'm new to wine, looking into serial communications.  I have a failing
> scenario in a application, and I'd like to write a conformance test to
> demonstrate/document the issue.  I looked in dlls/ntdll/tests but did
> not see any serial port related tests - did I miss them or do none
> exist yet?  Assuming none exist, a very useful tool would be a serial
> port loopback device.  Rather than require conformance testers to
> attach a hardware loopback device (NULL modem) to a physical port,
> could we create some virtual ports in wine and connect them together?
> Maybe com98 and com99 for example?  Anything written to one of the
> ports would be sent to the other one.  On Windows this can be done
> with a device driver, one example is com0com
> (http://com0com.sourceforge.net/).
> Is this a reasonable approach?  Thanks,

Serial data and ioctls are forwarded straight to the kernel, so you'd
need to put the loopback driver in the kernel, not in Wine.

-- 
Alexandre Julliard
julliard(a)winehq.org

[Saulius Krasuckas]

* On Mon, 23 Mar 2009, Chris Teague wrote:
> very useful tool would be a serial port loopback device.  Rather than 
> require conformance testers to attach a hardware loopback device (NULL 
> modem) to a physical port, could we create some virtual ports in wine 
> and connect them together? Maybe com98 and com99 for example?  Anything 
> written to one of the ports would be sent to the other one.

Chris, none of my very business, but do you need to test only Tx/Rx lines, 
o some more? (like DTR, RTS and the rest)


* On Tue, 24 Mar 2009, Alexandre Julliard wrote:
> Serial data and ioctls are forwarded straight to the kernel, so you'd 
> need to put the loopback driver in the kernel, not in Wine.

Basic tests could probably cover Tx/Rx signals only, so IMHO none kernel 
module would be necessary -- some user space app can suffice (remserial, 
socat, nullmodem).  But that would tie such test to a specific 
configuration of a particular linux box...

Alexandre, for the core operation your proposal sounds very reasonable, 
but in the case of winetest, how it would work on Windows?

For tests, I suppose Wine really needs some stubby serial driver (eg one 
comming from the mentioned com0com), which would then communicate with 
ntdll/wineserver, where the missing functionality could probably be 
redirected to the linux kernel, when it's implemented there.  No?


With regard to Chris: personally I would start hacking at making com0com 
to work on Wine.

[Damjan Jovanovic]

On Tue, Mar 24, 2009 at 12:06 AM, Chris Teague <chris.teague(a)gmail.com> wrote:
> I'm new to wine, looking into serial communications.  I have a failing
> scenario in a application, and I'd like to write a conformance test to
> demonstrate/document the issue.  I looked in dlls/ntdll/tests but did
> not see any serial port related tests - did I miss them or do none
> exist yet?  Assuming none exist, a very useful tool would be a serial
> port loopback device.  Rather than require conformance testers to
> attach a hardware loopback device (NULL modem) to a physical port,
> could we create some virtual ports in wine and connect them together?
> Maybe com98 and com99 for example?  Anything written to one of the
> ports would be sent to the other one.  On Windows this can be done
> with a device driver, one example is com0com
> (http://com0com.sourceforge.net/).
> Is this a reasonable approach?  Thanks,
> Chris

What's wrong, does nobody care or is it not worth it? Well I care, and
I think it's very much worth it. The number of serial port bugs in
Bugzilla alone, seems to indicate a dire need.

I saw one of the BSDs has a null modem driver that emulates a pair of
connected serial ports as a standard part of the kernel
(http://fxr.watson.org/fxr/source/dev/nmdm/nmdm.c), while Linux not
only hasn't got it, but when a guy sent a patch into LKML some years
ago it got... completely ignored (found that mail once by accident
after hours of googling, couldn't find it again).

With a virtual serial port you can do all sorts of nifty things,
serial to RFC 2217 allowing access to remote serial port hardware,
sharing read-only hardware like GPSes over several virtual serial
ports, and monitoring communication between an application and a real
serial port. "Mighty handy for use with serial console in Vmware"
reads a comment in the BSD driver. Regression testing Wine is just one
useful side effect.

So I'll be resuming my work on a virtual serial port kernel module for
Linux. It's a shame we still don't have one in 2009.

Damjan