Hi all.
I’m developing a KMDF function driver for a custom PCI board (it’s an
off-the-shelf card, I have no control over its design). I have a device
object for every PDO. Nothing special in that. The driver should also expose
a device object that is not attached to a specific PDO, but is instead
“virtually” attached to more than one of them (it basically aggregates data
coming from multiple PDO’s). This (aggregating) device object should be
theoretically created only when all the PDO’s that I aggregate is added, and
destroyed as soon as one PDO disappear. The driver can create multiple
aggregating device objects.
I was thinking of using control device objects, but I don’t know if there is
a better solution to the problem.
Any suggestion?
Have a nice day
GV
Gianluca Varenni wrote:
I’m developing a KMDF function driver for a custom PCI board (it’s an
off-the-shelf card, I have no control over its design). I have a
device object for every PDO. Nothing special in that. The driver
should also expose a device object that is not attached to a specific
PDO, but is instead “virtually” attached to more than one of them (it
basically aggregates data coming from multiple PDO’s). This
(aggregating) device object should be theoretically created only when
all the PDO’s that I aggregate is added, and destroyed as soon as one
PDO disappear. The driver can create multiple aggregating device objects.
I was thinking of using control device objects, but I don’t know if
there is a better solution to the problem.
A control device object is certainly one way to do this. Do you have to
talk to this PDO from user-mode?
You could also have the first driver in create the control PDO, have
additional drivers register with it, and have it enable and disable a
device interface as the number of devices crosses your threshhold.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
----- Original Message -----
From: “Tim Roberts”
To: “Windows System Software Devs Interest List”
Sent: Thursday, October 11, 2007 4:10 PM
Subject: Re: [ntdev] Advice on control device object in a function driver
> Gianluca Varenni wrote:
>>
>> I’m developing a KMDF function driver for a custom PCI board (it’s an
>> off-the-shelf card, I have no control over its design). I have a
>> device object for every PDO. Nothing special in that. The driver
>> should also expose a device object that is not attached to a specific
>> PDO, but is instead “virtually” attached to more than one of them (it
>> basically aggregates data coming from multiple PDO’s). This
>> (aggregating) device object should be theoretically created only when
>> all the PDO’s that I aggregate is added, and destroyed as soon as one
>> PDO disappear. The driver can create multiple aggregating device objects.
>>
>> I was thinking of using control device objects, but I don’t know if
>> there is a better solution to the problem.
>
> A control device object is certainly one way to do this. Do you have to
> talk to this PDO from user-mode?
Yes. The user-mode code should be able to communicate with the normal FDOs
or with these aggregating device objects.
> You could also have the first driver in create the control PDO, have
> additional drivers register with it, and have it enable and disable a
> device interface as the number of devices crosses your threshhold.
>
Are you suggesting a multiple driver solution, i.e. a bus driver exposing
the original PDOs and these additional aggregating devices as PDOs?
Have a nice day
GV
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
----- Original Message -----
From: “Gianluca Varenni”
To: “Windows System Software Devs Interest List”
Sent: Thursday, October 11, 2007 4:33 PM
Subject: Re: [ntdev] Advice on control device object in a function driver
>
> ----- Original Message -----
> From: “Tim Roberts”
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, October 11, 2007 4:10 PM
> Subject: Re: [ntdev] Advice on control device object in a function driver
>
>
>> Gianluca Varenni wrote:
>>>
>>> I’m developing a KMDF function driver for a custom PCI board (it’s an
>>> off-the-shelf card, I have no control over its design). I have a
>>> device object for every PDO. Nothing special in that. The driver
>>> should also expose a device object that is not attached to a specific
>>> PDO, but is instead “virtually” attached to more than one of them (it
>>> basically aggregates data coming from multiple PDO’s). This
>>> (aggregating) device object should be theoretically created only when
>>> all the PDO’s that I aggregate is added, and destroyed as soon as one
>>> PDO disappear. The driver can create multiple aggregating device
>>> objects.
>>>
>>> I was thinking of using control device objects, but I don’t know if
>>> there is a better solution to the problem.
>>
>> A control device object is certainly one way to do this. Do you have to
>> talk to this PDO from user-mode?
>
> Yes. The user-mode code should be able to communicate with the normal FDOs
> or with these aggregating device objects.
>
>
>> You could also have the first driver in create the control PDO, have
>> additional drivers register with it, and have it enable and disable a
>> device interface as the number of devices crosses your threshhold.
>>
>
> Are you suggesting a multiple driver solution, i.e. a bus driver exposing
> the original PDOs and these additional aggregating devices as PDOs?
>
[…forgot a piece of the sentence…]
Are you suggesting a multiple driver solution, i.e. a bus driver exposing
the original PDOs and these additional aggregating devices as PDOs and
another function driver on top of this bus driver?
GV
> Have a nice day
> GV
>
>
>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> 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
>
Gianluca Varenni wrote:
> You could also have the first driver in create the control PDO, have
> additional drivers register with it, and have it enable and disable a
> device interface as the number of devices crosses your threshhold.
>
Are you suggesting a multiple driver solution, i.e. a bus driver
exposing the original PDOs and these additional aggregating devices as
PDOs?
No, although you certainly could do that.
You will have to keep a “driver count” in a global somewhere. What you
said was something like this:
if( InterlockedIncrement( gDriverInstanceCount ) == 4 )
GoLaunchControlDevice();
with corresponding code in the take down side. However, that begs the
question of how will the control device FIND the devices it is going to
aggregate?
An alternative is to say:
…grab some lock…
if( gDriverInstanceCount == 0 )
GoLaunchControlDevice();
gDriverInstanceCount++;
…release lock…
GoRegisterWithControlDevice();
That is, the control device starts running with the first aggregating
device, and gets told about each additional one.
Same results, different style.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Why do you need to aggregate? Instead of doing the aggregation in the driver, can you do it in a user mode service? That would be much simpler. How do you know when you get “all” of the devices to aggregrate?
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Thursday, October 11, 2007 3:24 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Advice on control device object in a function driver
Hi all.
I’m developing a KMDF function driver for a custom PCI board (it’s an
off-the-shelf card, I have no control over its design). I have a device
object for every PDO. Nothing special in that. The driver should also expose
a device object that is not attached to a specific PDO, but is instead
“virtually” attached to more than one of them (it basically aggregates data
coming from multiple PDO’s). This (aggregating) device object should be
theoretically created only when all the PDO’s that I aggregate is added, and
destroyed as soon as one PDO disappear. The driver can create multiple
aggregating device objects.
I was thinking of using control device objects, but I don’t know if there is
a better solution to the problem.
Any suggestion?
Have a nice day
GV
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
The more I think of it, and the more I think that aggregating at user level
(in a service or directly in the user DLL that I will use as a layer of
communication to the driver) is much simpler. No problems of PDO’s getting
removed while I have open handles to the aggregating DO, cleaner design in
the driver. I’m just a bit worried of (maybe) needing to perform an
additional copy of the data at user level (each stream of data I’m
aggregating is up to 1Gbps).
I think I will probably go with user level aggregation, and then measure the
performance I get in this way.
Thanks for the suggestion
GV
----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Thursday, October 11, 2007 7:14 PM
Subject: RE: [ntdev] Advice on control device object in a function driver
Why do you need to aggregate? Instead of doing the aggregation in the
driver, can you do it in a user mode service? That would be much simpler.
How do you know when you get “all” of the devices to aggregrate?
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Thursday, October 11, 2007 3:24 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Advice on control device object in a function driver
Hi all.
I’m developing a KMDF function driver for a custom PCI board (it’s an
off-the-shelf card, I have no control over its design). I have a device
object for every PDO. Nothing special in that. The driver should also expose
a device object that is not attached to a specific PDO, but is instead
“virtually” attached to more than one of them (it basically aggregates data
coming from multiple PDO’s). This (aggregating) device object should be
theoretically created only when all the PDO’s that I aggregate is added, and
destroyed as soon as one PDO disappear. The driver can create multiple
aggregating device objects.
I was thinking of using control device objects, but I don’t know if there is
a better solution to the problem.
Any suggestion?
Have a nice day
GV
—
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
----- Original Message -----
From: “Tim Roberts”
To: “Windows System Software Devs Interest List”
Sent: Thursday, October 11, 2007 5:03 PM
Subject: Re: [ntdev] Advice on control device object in a function driver
> Gianluca Varenni wrote:
>>
>>
>>> You could also have the first driver in create the control PDO, have
>>> additional drivers register with it, and have it enable and disable a
>>> device interface as the number of devices crosses your threshhold.
>>>
>>
>> Are you suggesting a multiple driver solution, i.e. a bus driver
>> exposing the original PDOs and these additional aggregating devices as
>> PDOs?
>
> No, although you certainly could do that.
>
> You will have to keep a “driver count” in a global somewhere. What you
> said was something like this:
>
> if( InterlockedIncrement( gDriverInstanceCount ) == 4 )
> GoLaunchControlDevice();
>
> with corresponding code in the take down side. However, that begs the
> question of how will the control device FIND the devices it is going to
> aggregate?
>
> An alternative is to say:
>
> …grab some lock…
> if( gDriverInstanceCount == 0 )
> GoLaunchControlDevice();
> gDriverInstanceCount++;
> …release lock…
> GoRegisterWithControlDevice();
>
> That is, the control device starts running with the first aggregating
> device, and gets told about each additional one.
>
A similar approach is actually what I’ve already implemented as a mockup
this afternoon (aggregating all the PDO’s, basically). What worries me more
is dealing with PDOs getting removed while there are open handles to the
aggregating DO…
I think that aggregating at user level (Doron’s suggestion) should
definitely simplify things.
Have a nice day
GV
> Same results, different style.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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