UMDF questions

Michal_Vodicka-2 · November 16, 2007, 3:13pm

I was asked to consider an idea of using UMDF a way which may or may not be possible (can’t give too much details because of NDA and similar nonsense). I know almost nothing about UMDF except it uses COM (which is discouraging enough and I’m just printing documents to study at weekend. So please forgive my ignorance in this area and let me ask few questions:

if I understand correctly, UMDF driver can talk to hardware via supplied kernel drivers as WinUsb. But what if it is necessary to use unsupported hardware which is accesible via 3rd party driver which knows nothing about UMDF and can’t be changed? Is is possible to build UMDF driver using it? Currently it is used standard way (find devices using Setup API and communicate via Read/Write/IOCTL). There are more hw flavors which’d have to be accessed this way. One other example are devices connected via serial line, next accessed using SCSI passthough and so on.
are UMDF sources available? I presume the same as for KMDF. In this case, are they accesible for MVPs?

TIA.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Tim_Roberts · November 16, 2007, 5:51pm

Michal Vodicka wrote:

I was asked to consider an idea of using UMDF a way which may or may not be possible (can’t give too much details because of NDA and similar nonsense). I know almost nothing about UMDF except it uses COM (which is discouraging enough

It is uses a COM-like architecture. Basically, that means it uses the
interface concept, which is just using pure virtual base classes to
define the behavior. It’s just a good, flexible programming practice.
UMDF doesn’t use all of the registry, proxy, and marshalling magic of COM.

and I’m just printing documents to study at weekend. So please forgive my ignorance in this area and let me ask few questions:

if I understand correctly, UMDF driver can talk to hardware via supplied kernel drivers as WinUsb. But what if it is necessary to use unsupported hardware which is accesible via 3rd party driver which knows nothing about UMDF and can’t be changed? Is is possible to build UMDF driver using it?

No. At this point, UMDF is usable only for a small list of well-defined
protocol bus devices, like 1394, USB and Bluetooth.

Currently it is used standard way (find devices using Setup API and communicate via Read/Write/IOCTL). There are more hw flavors which’d have to be accessed this way.

It sounds like you already HAVE a driver. Why do you need UMDF?

are UMDF sources available? I presume the same as for KMDF. In this case, are they accesible for MVPs?

Not yet.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

OSR_Community_User · November 16, 2007, 6:14pm

UMDF uses the COM programming pattern (reference counted interfaces). It doesn’t use the COM runtime - no registration, no weird memory allocators, etc…

A UMDF driver has to be loaded on a PNP device stack, so whatever you talk to needs some sort of enumerator. However once that’s done it can communicate with other drivers in the following ways:

When attached to a USB device stack it can use the USB I/O target to talk to control/bulk/interrupt pipes on that device (no isoch).
When attached to a device stack that accepts read/write/ioctl (not internal IOCTL) it can use the default I/O target to send those to the lower drivers.
Sometimes the enumerator may not provide any I/O path. The simplest example is a root-enumerated device. Another is an IP connected device, which is enumerated by UMBUS but must be accessed through sockets. Here you have two options:

3a) You can open a handle to the device and then use our Win32 I/O target to send read/write/ioctl requests to the device even though it’s not in your stack.

3b) You can use other Win32 APIs, say WinSock, to communicate with your device.

If you already have an application that can talk to your device then you should be able to write a user-mode driver that does the same things the app does. The cases where you’d need something new are if you are replacing a KM driver that uses or receives internal I/O controls (other than URBs which WinUSB handles for us), or if you have another KM component that attempts to open your device or sit on top of your device. If you feel you need those then we should probably chat separately.

I’m never sure how much source access MVPs have so one of them would have to answer the last question.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, November 16, 2007 12:13 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] UMDF questions

I was asked to consider an idea of using UMDF a way which may or may not be possible (can’t give too much details because of NDA and similar nonsense). I know almost nothing about UMDF except it uses COM (which is discouraging enough and I’m just printing documents to study at weekend. So please forgive my ignorance in this area and let me ask few questions:

if I understand correctly, UMDF driver can talk to hardware via supplied kernel drivers as WinUsb. But what if it is necessary to use unsupported hardware which is accesible via 3rd party driver which knows nothing about UMDF and can’t be changed? Is is possible to build UMDF driver using it? Currently it is used standard way (find devices using Setup API and communicate via Read/Write/IOCTL). There are more hw flavors which’d have to be accessed this way. One other example are devices connected via serial line, next accessed using SCSI passthough and so on.
are UMDF sources available? I presume the same as for KMDF. In this case, are they accesible for MVPs?

TIA.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

Michal_Vodicka-2 · November 16, 2007, 6:18pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Tim Roberts[SMTP:xxxxx@probo.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, November 16, 2007 11:50 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] UMDF questions

It is uses a COM-like architecture. Basically, that means it uses the
interface concept, which is just using pure virtual base classes to
define the behavior. It’s just a good, flexible programming practice.
UMDF doesn’t use all of the registry, proxy, and marshalling magic of COM.

Sounds good, thanks.

No. At this point, UMDF is usable only for a small list of well-defined
protocol bus devices, like 1394, USB and Bluetooth.

So UMDF driver can’t use Setup API to enumerate devices and Win32 APIs to access them? Yes, I see a problem with PnP (who’d load such a driver and why?)

It sounds like you already HAVE a driver. Why do you need UMDF?

*I* don’t need UMDF and I’d prefer to never hear about it… Basically, the purpose is to replace existing solution with one which will be more complicated, less flexible and less stable but will need much more work to implement. Sorry, can’t talk about it more.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

OSR_Community_User · November 16, 2007, 7:00pm

Michal:

I don’t know whether UMDF comes under a MVPSLP or not. If you haven’t
already, you might want to check out:

https://mvp.support.microsoft.com/gp/MVPsecSSource

In particular, without querying the specifics of your project, it’s a
reference only license, and this below seems like it might be a deal
breaker as well:

“MVPs may not use the knowledge gained via the source code to develop
their own commercially distributed software. This includes software that
MVPs are creating for commercial use in a customer development
consulting practice.”

Considering the restrictions listed on that page, I can’t imagine what
the actual NDA looks like. While there is absolutely no way I would
sign anything that I imagine that NDA looks like, considering the costs
of contamination and I don’t see any way one could defend oneself
against any such charges considering that paragraph I quoted above, I
filled out the ‘program survey wizard,’ that apparently is the first
step to fulfilling this process, just to see what the NDA looks like,
but never heard anything (maybe four months ago). I didn’t proceed
further, as I was basically doing it only to find out what my options
are, and it wasn’t worth the trouble. That being said, there are people
on this list that I believe have obtained source code access through the
MVP program, so maybe I did something wrong, or missed the e-mail or
whatnot, but, if you’re going to look in to it, and you have some sort
of near future time frame, I would not personally rely on the wizard.

For whatever it is worth,

mm

Michal Vodicka wrote:

I was asked to consider an idea of using UMDF a way which may or may not be possible (can’t give too much details because of NDA and similar nonsense). I know almost nothing about UMDF except it uses COM (which is discouraging enough and I’m just printing documents to study at weekend. So please forgive my ignorance in this area and let me ask few questions:

if I understand correctly, UMDF driver can talk to hardware via supplied kernel drivers as WinUsb. But what if it is necessary to use unsupported hardware which is accesible via 3rd party driver which knows nothing about UMDF and can’t be changed? Is is possible to build UMDF driver using it? Currently it is used standard way (find devices using Setup API and communicate via Read/Write/IOCTL). There are more hw flavors which’d have to be accessed this way. One other example are devices connected via serial line, next accessed using SCSI passthough and so on.

are UMDF sources available? I presume the same as for KMDF. In this case, are they accesible for MVPs?

TIA.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Michal_Vodicka-2 · November 16, 2007, 7:03pm

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Peter Wieland[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Saturday, November 17, 2007 12:13 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UMDF questions

UMDF uses the COM programming pattern (reference counted interfaces). It doesn’t use the COM runtime - no registration, no weird memory allocators, etc…

Glad to know. I have nothing against reference counted interface (invented some :); I was worrying about the rest hearing horror stories from my user mode coworkers

A UMDF driver has to be loaded on a PNP device stack, so whatever you talk to needs some sort of enumerator. However once that’s done it can communicate with other drivers in the following ways:

When attached to a USB device stack it can use the USB I/O target to talk to control/bulk/interrupt pipes on that device (no isoch).

Are there any limitation against kernel mode driver related to asychrounous I/O? In our case the only way how to achieve necessary performance for USB devices is to have several bulk-in URBs always queued and processed by seperate thread.

When attached to a device stack that accepts read/write/ioctl (not internal IOCTL) it can use the default I/O target to send those to the lower drivers.

Is it possible to attach any device stack accepting read/write/ioctl or are there some limitations? If yes, it would be sufficient for one case (3rd party driver). How to make this relation? I presume it would have to be made at UMDF driver installation time.

Sometimes the enumerator may not provide any I/O path. The simplest example is a root-enumerated device. Another is an IP connected device, which is enumerated by UMBUS but must be accessed through sockets. Here you have two options:

3a) You can open a handle to the device and then use our Win32 I/O target to send read/write/ioctl requests to the device even though it’s not in your stack.

It would be the case for SCSI passthrough devices I guess.

3b) You can use other Win32 APIs, say WinSock, to communicate with your device.

I presume serial line which uses more Win32 APIs would need this.

If you already have an application that can talk to your device then you should be able to write a user-mode driver that does the same things the app does.

This is exactly what I’d need.

If I understand correctly, the only real problem is the enumerator. Can you elaborate this part more? There should be one UMDF device per real device instance. I’m not sure if it is possible to achieve using root enumerated device i.e if it is possible to make a dependency on existing devices. Currently, application uses Setup API to enumerate available interfaces or accesses devices based on configuration or user input (for example, user attaches device to COM1 and gives app parameters which says this, speed and so on).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

OSR_Community_User · November 16, 2007, 7:36pm

UMDF drivers can receive and send asynchronous I/O. We follow the WDF I/O target model and allow you to issue multiple outstanding operations. Asynchronous completion of I/O you send through the I/O target is handled using completion ports and a thread pool which retrives the OVERLAPPED structure, finds the associated request and invokes your completion routine.

The installation details are in the WDK and in the WDF book. UMDF drivers install through INFs like kernel-mode drivers. You put our reflector on the device stack in the right spot for your design, then use UMDF specific directives to install your user-mode drivers and setup your user-mode driver list. Your INF invokes our coinstaller which installs UMDF if it’s not present and interprets the UMDF specific directives. There isn’t any limit on what you can attach to (as long as the user-mode drivers are the top drivers) - if there’s a PNP device node you can attach to it.

As to the specific examples you cite … for SCSI pass-through I would install on the PDO for the SCSI LUN and then issue pass-through i/o controls through the default I/O target. For serial port you may be able to load your driver on top of the serial port … I’ve never tried that but I think one other team has … or create a root-enumerated device manually and then open \.\COMn to get at the serial port.

I think one thing that’s not clear is how your driver finds the device. In general you rely on PNP for that, by loading in the stack just like any PNP driver would. Hopefully that should also answer your question about the root-enumerated device as well.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, November 16, 2007 4:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UMDF questions

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Peter Wieland[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Saturday, November 17, 2007 12:13 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UMDF questions

UMDF uses the COM programming pattern (reference counted interfaces). It doesn’t use the COM runtime - no registration, no weird memory allocators, etc…

Glad to know. I have nothing against reference counted interface (invented some :); I was worrying about the rest hearing horror stories from my user mode coworkers

A UMDF driver has to be loaded on a PNP device stack, so whatever you talk to needs some sort of enumerator. However once that’s done it can communicate with other drivers in the following ways:

When attached to a USB device stack it can use the USB I/O target to talk to control/bulk/interrupt pipes on that device (no isoch).

Are there any limitation against kernel mode driver related to asychrounous I/O? In our case the only way how to achieve necessary performance for USB devices is to have several bulk-in URBs always queued and processed by seperate thread.

When attached to a device stack that accepts read/write/ioctl (not internal IOCTL) it can use the default I/O target to send those to the lower drivers.

Is it possible to attach any device stack accepting read/write/ioctl or are there some limitations? If yes, it would be sufficient for one case (3rd party driver). How to make this relation? I presume it would have to be made at UMDF driver installation time.

Sometimes the enumerator may not provide any I/O path. The simplest example is a root-enumerated device. Another is an IP connected device, which is enumerated by UMBUS but must be accessed through sockets. Here you have two options:

3a) You can open a handle to the device and then use our Win32 I/O target to send read/write/ioctl requests to the device even though it’s not in your stack.

It would be the case for SCSI passthrough devices I guess.

3b) You can use other Win32 APIs, say WinSock, to communicate with your device.

I presume serial line which uses more Win32 APIs would need this.

If you already have an application that can talk to your device then you should be able to write a user-mode driver that does the same things the app does.

This is exactly what I’d need.

If I understand correctly, the only real problem is the enumerator. Can you elaborate this part more? There should be one UMDF device per real device instance. I’m not sure if it is possible to achieve using root enumerated device i.e if it is possible to make a dependency on existing devices. Currently, application uses Setup API to enumerate available interfaces or accesses devices based on configuration or user input (for example, user attaches device to COM1 and gives app parameters which says this, speed and so on).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

Michal_Vodicka-2 · November 16, 2007, 8:59pm

Thanks, Peter. I guess I know enough for now. I’ll study docs and probably will have more questions later

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Peter Wieland[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Saturday, November 17, 2007 1:35 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UMDF questions

UMDF drivers can receive and send asynchronous I/O. We follow the WDF I/O target model and allow you to issue multiple outstanding operations. Asynchronous completion of I/O you send through the I/O target is handled using completion ports and a thread pool which retrives the OVERLAPPED structure, finds the associated request and invokes your completion routine.

The installation details are in the WDK and in the WDF book. UMDF drivers install through INFs like kernel-mode drivers. You put our reflector on the device stack in the right spot for your design, then use UMDF specific directives to install your user-mode drivers and setup your user-mode driver list. Your INF invokes our coinstaller which installs UMDF if it’s not present and interprets the UMDF specific directives. There isn’t any limit on what you can attach to (as long as the user-mode drivers are the top drivers) - if there’s a PNP device node you can attach to it.

As to the specific examples you cite … for SCSI pass-through I would install on the PDO for the SCSI LUN and then issue pass-through i/o controls through the default I/O target. For serial port you may be able to load your driver on top of the serial port … I’ve never tried that but I think one other team has … or create a root-enumerated device manually and then open \.\COMn to get at the serial port.

I think one thing that’s not clear is how your driver finds the device. In general you rely on PNP for that, by loading in the stack just like any PNP driver would. Hopefully that should also answer your question about the root-enumerated device as well.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, November 16, 2007 4:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UMDF questions

> ----------
> From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Peter Wieland[SMTP:xxxxx@windows.microsoft.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Saturday, November 17, 2007 12:13 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] UMDF questions
>
> UMDF uses the COM programming pattern (reference counted interfaces). It doesn’t use the COM runtime - no registration, no weird memory allocators, etc…
>
Glad to know. I have nothing against reference counted interface (invented some :); I was worrying about the rest hearing horror stories from my user mode coworkers

> A UMDF driver has to be loaded on a PNP device stack, so whatever you talk to needs some sort of enumerator. However once that’s done it can communicate with other drivers in the following ways:
>
> 1. When attached to a USB device stack it can use the USB I/O target to talk to control/bulk/interrupt pipes on that device (no isoch).
>
Are there any limitation against kernel mode driver related to asychrounous I/O? In our case the only way how to achieve necessary performance for USB devices is to have several bulk-in URBs always queued and processed by seperate thread.

> 2. When attached to a device stack that accepts read/write/ioctl (not internal IOCTL) it can use the default I/O target to send those to the lower drivers.>
>
Is it possible to attach any device stack accepting read/write/ioctl or are there some limitations? If yes, it would be sufficient for one case (3rd party driver). How to make this relation? I presume it would have to be made at UMDF driver installation time.

> 3. Sometimes the enumerator may not provide any I/O path. The simplest example is a root-enumerated device. Another is an IP connected device, which is enumerated by UMBUS but must be accessed through sockets. Here you have two options:
>
> 3a) You can open a handle to the device and then use our Win32 I/O target to send read/write/ioctl requests to the device even though it’s not in your stack.
>
It would be the case for SCSI passthrough devices I guess.

> 3b) You can use other Win32 APIs, say WinSock, to communicate with your device.
>
I presume serial line which uses more Win32 APIs would need this.

> If you already have an application that can talk to your device then you should be able to write a user-mode driver that does the same things the app does.
>
This is exactly what I’d need.

If I understand correctly, the only real problem is the enumerator. Can you elaborate this part more? There should be one UMDF device per real device instance. I’m not sure if it is possible to achieve using root enumerated device i.e if it is possible to make a dependency on existing devices. Currently, application uses Setup API to enumerate available interfaces or accesses devices based on configuration or user input (for example, user attaches device to COM1 and gives app parameters which says this, speed and so on).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

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