Help with Non-pnp to Pnp Driver communication

OSR_Community_User · December 10, 2007, 2:41pm

Hi,
I am just starting out with Windows driver development and I have read through the archives but couldnt find exactly what i was looking for.

I am writing a Kmdf driver (non-PnP) that communicates with the serial port driver (PnP) and reads data from the serial port and performs complex calculations based on the values from the data. Occasionally it might send out some data too.

I am not sure if i would call this driver a filter driver because it doesnt alter the requests being sent to serial port in anyway. In another words, this is exactly similar to an application running on the kernel mode. I have created a queue and registered call-back functions for handling the requests.

My questions are: Should i have to register for Device interface with serial port GUID? how do i make the framework invoke my Call back functions for the queue when there is data on the serial buffer?

It will be really helpful if you could give me some info or atleast guide me to an article suggesting this kind of mechanism.

Thanks.

Regards,
Thor

OSR_Community_User · December 10, 2007, 2:48pm

Why is this even a driver? What you described is an application that
reads and writes the serial port.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@rediffmail.com
Sent: Monday, December 10, 2007 2:40 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Help with Non-pnp to Pnp Driver communication

Hi,
I am just starting out with Windows driver development and I have read
through the archives but couldnt find exactly what i was looking for.

I am writing a Kmdf driver (non-PnP) that communicates with the serial
port driver (PnP) and reads data from the serial port and performs
complex calculations based on the values from the data. Occasionally it
might send out some data too.

I am not sure if i would call this driver a filter driver because it
doesnt alter the requests being sent to serial port in anyway. In
another words, this is exactly similar to an application running on the
kernel mode. I have created a queue and registered call-back functions
for handling the requests.

My questions are: Should i have to register for Device interface with
serial port GUID? how do i make the framework invoke my Call back
functions for the queue when there is data on the serial buffer?

It will be really helpful if you could give me some info or atleast
guide me to an article suggesting this kind of mechanism.

Thanks.

Regards,
Thor

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

OSR_Community_User · December 10, 2007, 3:02pm

I see your suggestion, but the change in design is not possible at this point.
There are certain features which are available only accessible on the kernel mode. There is also an algorithm that involves lot of floating point arithmetic directly interacting with the FPU.
Its a simple driver invoking an algorithm with the data from the serial port. I want to know how to to achieve this kind of communication between two drivers.
Thanks for your input.
reg,
thor

Tim_Roberts · December 10, 2007, 3:07pm

xxxxx@rediffmail.com wrote:

I am just starting out with Windows driver development and I have read through the archives but couldnt find exactly what i was looking for.

I am writing a Kmdf driver (non-PnP) that communicates with the serial port driver (PnP) and reads data from the serial port and performs complex calculations based on the values from the data. Occasionally it might send out some data too.

How are you communicating with the serial port? Or is that what you
need to decide?

I am not sure if i would call this driver a filter driver because it doesnt alter the requests being sent to serial port in anyway. In another words, this is exactly similar to an application running on the kernel mode. I have created a queue and registered call-back functions for handling the requests.

In that case, why is this a kernel driver at all? You should only
resort to kernel code when it is absolutely necessary. Everything else
belongs in user mode. It sounds like it isn’t absolutely necessary in
your case.

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

OSR_Community_User · December 10, 2007, 3:19pm

Hi Tim,
Thanks for your input. I understand the points you are making.
But, it is not whether it is necessary or not, that is bothering me. It is how does a non-pnp driver communicates with a pnp-driver and to make the pnp-driver send data to I/O queue of non-pnp driver?

I am resorting to kernel mode because of the stuff i am reading through the serial port is critical to some proprietary work that we are doing and that has to run be run only in kernel mode. So i am just writing a kernel mode driver that can read the data from serial port

Thanks for your input.

reg,
thor

Doron_Holan · December 10, 2007, 3:38pm

There is nothing about kernel mode that makes a computation faster or more precise. Reading from a kernel mode driver will not make it faster to process the data. I highly doubt that the completion of an IRP will introduce enough delay in your UM application to process the critical data in UM. In addition, FP use in the kernel must be monitored closely b/c you must correctly save/restore FP state in the driver, otherwise you can easily corrupt another application’s FP state. Tim is 100%, there is no need for this to be a driver. “It is too late, I have gone down a path from which I cannot return” is not a valid argument. Think of the tradeoff in complexity, maintenance, and debugability of a KM driver vs an application. If it can be done in UM, do it there.

to find the serial port, use IoRegisterPlugPlayNotifcation and specify PNPNOTIFY_DEVICE_INTERFACE_INCLUDE_EXISTING_INTERFACES to be told of existing com ports. Specify the com port device interface guid.
in the callback you specified in 1), create a WDFIOTARGET and open it
create a WDFREQUEST(s), format it (them), specify a completion routine and send it to the WDFIOTARGET
process the results in the completion routine

WDFIOTARGETs are not tied to your WDFIOQUEUE callbacks. You can use the WDFREQUESTs presented to the WDFIOQUEUE callbacks in sending to a WDFIOTARGET if there is enough stack locations in the underlying WDM IRP, but it is probably best for you to just allocate your own WDFREQUESTs and send those to the WDFIOTARGET and just complete the queue presented requests as needed based on state.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@rediffmail.com
Sent: Monday, December 10, 2007 12:18 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Help with Non-pnp to Pnp Driver communication

Hi Tim,
Thanks for your input. I understand the points you are making.
But, it is not whether it is necessary or not, that is bothering me. It is how does a non-pnp driver communicates with a pnp-driver and to make the pnp-driver send data to I/O queue of non-pnp driver?

I am resorting to kernel mode because of the stuff i am reading through the serial port is critical to some proprietary work that we are doing and that has to run be run only in kernel mode. So i am just writing a kernel mode driver that can read the data from serial port

Thanks for your input.

reg,
thor

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

OSR_Community_User · December 10, 2007, 4:02pm

> I see your suggestion, but the change in design is not possible at this

point.
There are certain features which are available only accessible on the
kernel mode. There is also an algorithm that involves lot of floating
point arithmetic directly interacting with the FPU.
Its a simple driver invoking an algorithm with the data from the serial
port. I want to know how to to achieve this kind of communication between
two drivers.

I’d have to second Mark’s view on WHY is this even a driver. Serial ports
deliver typically a maximum of about 10 kilobytes/sec. A reason you might
want something doing I/O as a driver would be to avoid significant overhead
of mapping received data into a user process, but the data rates from a
serial port are trivial.

You said “it’s already designed as a driver”, yet my guess is changing the
design to a normal user mode process and getting it all working will be
easier/faster than getting a driver fully debugged. As your just starting
our writing drivers, this is doubly so. Future support will also be much
easier if it’s just a user mode app.

You’re aware that to debug a driver requires two machines connected via 1394
or a serial port? User mode debugging all can happen on one machine, or
remotely over a network.

You say your app does a lot of floating point calculations, which is yet
another reason to make it a user mode app. Using floating point in a kernel
driver can be intricate.

If you MUST make it a driver, perhaps you should the UMDF (user mode driver
framework), which is designed EXACTLY for cases where you need some kernel
mode facilities, yet you don’t need the performance benefits when you’re
moving lots of data.

Lots of us here have very significant experience in both user mode and
kernel work. If you explained WHY you think you need to write a driver we
could confirm that yes a driver would be needed or no a user mode process is
a much better fit.

If you’re just doing this for something like a class project, then yes we
could understand why you might want to a write a driver when it’s not
needed.

You’re also aware that you generally can’t just take random user mode C/C++
source code and compile it up inside a driver. The execution environment is
NOT a standard C/C++ application environment. Many of the standard C
run-time support functions simply will not function in a driver. If you need
to interact with a user for any reason, you may need to write a user mode
app anyway.

Jan

OSR_Community_User · December 10, 2007, 5:25pm

Hi Jan, Doron,
Thanks for your inputs on why it should be an application or umdf. I understand all the things you are saying. It is not required under normal circumstances, I agree. I understand that as i am new you guys are elaborating on the thing that i need to know/do. But please understand that I have my reasons for choosing a kernel mode driver as i too dont want to spend too much time debugging if i had a choice. “The why” is not the problem now. I am wondering about the HOW.

If you could help me on how to actually make a kernel mode non-pnp driver communicate with the PnP driver and retrieve data through the I/O queue, it will be really helpful. I mean irrespective of what the use is, there must be a way to achieve this and i couldnt find it in any of the archives on this subject.

Thanks for your time/efforts.

reg,
Thor

Doron_Holan · December 10, 2007, 6:02pm

I just told you how to open up the com port and send i/o to it. Driver initiated i/o does not go through your own i/o queues.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@rediffmail.com
Sent: Monday, December 10, 2007 2:24 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Help with Non-pnp to Pnp Driver communication

Hi Jan, Doron,
Thanks for your inputs on why it should be an application or umdf. I understand all the things you are saying. It is not required under normal circumstances, I agree. I understand that as i am new you guys are elaborating on the thing that i need to know/do. But please understand that I have my reasons for choosing a kernel mode driver as i too dont want to spend too much time debugging if i had a choice. “The why” is not the problem now. I am wondering about the HOW.

If you could help me on how to actually make a kernel mode non-pnp driver communicate with the PnP driver and retrieve data through the I/O queue, it will be really helpful. I mean irrespective of what the use is, there must be a way to achieve this and i couldnt find it in any of the archives on this subject.

Thanks for your time/efforts.

reg,
Thor

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

OSR_Community_User · December 10, 2007, 6:29pm

Thanks doron.
I think now i understand on how it has to be done.

Reg,
Thor

Maxim_S_Shatskih · December 10, 2007, 6:56pm

> I am writing a Kmdf driver (non-PnP) that communicates with the serial port
driver

(PnP) and reads data from the serial port and performs complex calculations
based on the values from the data. Occasionally it might send out some data
too.

Can your serial-attached hardware support the serial PnP protocol? if yes -
then you can employ SERENUM in your driver and be fully PnP.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Maxim_S_Shatskih · December 10, 2007, 6:57pm

>mode. There is also an algorithm that involves lot of floating point
arithmetic

directly interacting with the FPU.

Why is this bad in user mode? In kernel mode, it’s worse.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com