I am in the process of creating a UMDF driver that creates a virtual serial port that communicates through a named pipe. I am basing the design on the VirtualSerial example, similar to the other post on this forum that does the same thing except with sockets. My question is, where is the best place to actually open the named pipe. It seems to me that I should implement the IQueueCallbackCreate::OnCreateFile() method, creating the named pipe when the user application actually opens the port. However, where would I perform the corresponding close on the named pipe? I don’t see a corresponding interface where I am notified with the port is closed.
Why a named pipe for the back end? Are you communicating with another process locally or remotely? Either way, an RPC connection will probably be better for you.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Sunday, December 05, 2010 5:55 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] UMDF serial to named pipe
I am in the process of creating a UMDF driver that creates a virtual serial port that communicates through a named pipe. I am basing the design on the VirtualSerial example, similar to the other post on this forum that does the same thing except with sockets. My question is, where is the best place to actually open the named pipe. It seems to me that I should implement the IQueueCallbackCreate::OnCreateFile() method, creating the named pipe when the user application actually opens the port. However, where would I perform the corresponding close on the named pipe? I don’t see a corresponding interface where I am notified with the port is closed.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
I suppose a little background is in order. I am simulating a ship steering system. I have put together a virtual environment using HyperV that runs each of the devices on the steering network (steering controller, voyage management, etc.). Voyage management communicates with the steering controller via RS-422. Previously, I had set up a virtual environment on my desktop system using VirtualBox. VirtualBox allows you to redirect serial communication to a named pipe, so I was able to connect the two VMs through a pipe. Hyper-V doesn’t have the same support. In the future, we are planning a VMWare server which would make this easier, but I’m trying to get it to work with Hyper-V.
I’ve looked around for an existing solution to this, but I haven’t found anything that quite fits the bill. Also, I’ve done a few WDM drivers in the past (as well as taken OSR’s course), and thought this would be a good opportunity to learn UMDF. So, if there’s a better way to do this using UMDF, I’m open to suggestions. I’ve come across a serial-tcp virtual driver, along with a virtual null modem that in theory would have worked, but for some reason running these drivers on my VMs killed all my other network performance.
So, my goals are as follows:
Provide a way to provide serial communication between VMs on a Hyper-V server.
Get familiar with UMDF.
Beyond that, I’m open.
Hyper-V (both v1 and v2) natively support redirecting serial ports to named pipes (if you have found documentation that states otherwise, it is in error). Pull open the Settings page for a VM, select one of the two COM ports and choose the ‘Named pipe’ attachment option.
- S
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Sunday, December 05, 2010 9:14 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] UMDF serial to named pipe
I suppose a little background is in order. I am simulating a ship steering system. I have put together a virtual environment using HyperV that runs each of the devices on the steering network (steering controller, voyage management, etc.). Voyage management communicates with the steering controller via RS-422. Previously, I had set up a virtual environment on my desktop system using VirtualBox. VirtualBox allows you to redirect serial communication to a named pipe, so I was able to connect the two VMs through a pipe. Hyper-V doesn’t have the same support. In the future, we are planning a VMWare server which would make this easier, but I’m trying to get it to work with Hyper-V.
I’ve looked around for an existing solution to this, but I haven’t found anything that quite fits the bill. Also, I’ve done a few WDM drivers in the past (as well as taken OSR’s course), and thought this would be a good opportunity to learn UMDF. So, if there’s a better way to do this using UMDF, I’m open to suggestions. I’ve come across a serial-tcp virtual driver, along with a virtual null modem that in theory would have worked, but for some reason running these drivers on my VMs killed all my other network performance.
So, my goals are as follows:
Provide a way to provide serial communication between VMs on a Hyper-V server.
Get familiar with UMDF.
Beyond that, I’m open.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Yes I do exactly this - implement IQueueCallbackCreate::OnCreateFile() as a
trigger to open the underlying TCP/IP socket in my UMDF virtual serial
driver.
To catch the file close event and close the associated socket, I implement
IFileCallbackClose::OnCloseFile() on my device’s IUnknown interface, which
is registered when IWDFDriver::CreateDevice() is called.
IMHO this smells of poorly designed driver interfaces - the fact that the
OnCreateFile() method is called on the queue, but the corresponding
OnCloseFile() method is called on the device! However, it seems to work ok
(maybe it was designed this way for other reasons I am yet to appreciate).
Hope that helps,
Scott
On Mon, Dec 6, 2010 at 9:54 AM, wrote:
> I am in the process of creating a UMDF driver that creates a virtual serial
> port that communicates through a named pipe. I am basing the design on the
> VirtualSerial example, similar to the other post on this forum that does the
> same thing except with sockets. My question is, where is the best place to
> actually open the named pipe. It seems to me that I should implement the
> IQueueCallbackCreate::OnCreateFile() method, creating the named pipe when
> the user application actually opens the port. However, where would I perform
> the corresponding close on the named pipe? I don’t see a corresponding
> interface where I am notified with the port is closed.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Apparently Hyper-V only supports named pipe redirection to the parent partition. I have been unable to actually get two different VMs to communicate through serial ports redirected to the same named pipe. I am not alone in this finding.
Scott,
Thanks for the information. I’ll give this a shot and let you know how it turns out. I figure my architecture will be somewhat similar to yours. For a write operation, I will start an asynchronous write to the pipe and, upon completion, pull the next item of the queue and start that one. I’ll do basically the same thing for reads.
xxxxx@hotmail.com wrote:
Apparently Hyper-V only supports named pipe redirection to the parent partition. I have been unable to actually get two different VMs to communicate through serial ports redirected to the same named pipe. I am not alone in this finding.
That’s not hard to imagine. A named pipe has one server and many
clients, and it’s quite likely that Hyper-V expects to be the server.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>Hyper-V (both v1 and v2) natively support redirecting serial ports to named pipes
More so, Jake Oshins once told that this is optimized for WinDbg performance.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com