Doron
Wed Apr 18 00:34:35 CDT 2007
Johan, please post some code.
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Don Burn" <burn@stopspam.windrvr.com> wrote in message
news:uSiB09OgHHA.1312@TK2MSFTNGP05.phx.gbl...
> Johan,
>
> I'm sorry to say you are in an area I have not done enough to help you
> with. Doron is the expert here, and hopefully he can answer this for you
> quickly.
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website:
http://www.windrvr.com
> Blog:
http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> "Johan Paul" <johan.paul@gmail.com> wrote in message
> news:1176813327.008729.144820@p77g2000hsh.googlegroups.com...
>> Hi Don,
>>
>> Thanks for your reply!
>>
>> In this case we have a bus driver for a composite USB device and I try
>> to forward URBs from a child device down to the USB hub driver via the
>> parent driver. If I understood correctly, this is the scenario Oney
>> talks about (2nd. edition, page 543) when referring to as action
>> delegetion from (child) PDO down the (parent) FDO stack?
>>
>> What do you mean by most of the driver requests are automatically
>> handled by WDF? Do you mean that these IRPs containing URBs could be
>> forwarded and completed without me interfering at all?
>>
>> I have tried so many different things for this to work that it could
>> be that I don't see the simple solution ;)
>>
>>
>> Regards,
>>
>> Johan Paul
>>
>>> You haven't given enough context for most of us, what type of request
>>> are
>>> you trying to delegate? Most of the bus driver requests are handled by
>>> WDF
>>> in a way you do not have to worry about delegation. Tell us some more
>>> of
>>> the specifics of what you are doing, just referring to Oney's book (you
>>> didn't even say which version) is not helpful.
>>>
>>> --
>>> Don Burn (MVP, Windows DDK)
>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>> Website:
http://www.windrvr.com
>>> Blog:
http://msmvps.com/blogs/WinDrvr
>>> Remove StopSpam to reply
>>>
>>> "Johan Paul" <johan.p...@gmail.com> wrote in message
>>>
>>> news:1176792856.649968.93850@y5g2000hsa.googlegroups.com...
>>>
>>> > Hi all,
>>>
>>> > I am still wondering how on earth should the, what the book
>>> > "Programming the Microsoft Windows Driver Model" calls, delegate
>>> > action, be handled in WDF for a bus driver?
>>>
>>> > It seems very easy if you read the documentation; just take the
>>> > request, call WdfDeviceGetIoTarget() on the device that wants to
>>> > forward the request, send the request and that's about it. But as we
>>> > learned yesterday it doesn't work. WdfRequestSend() fails every time
>>> > although we verified that the target is working fine and can receive
>>> > ioctls created with WdfIoTargetSendInternalIoctlSynchronously(). The
>>> > same result even if we called
>>> > WdfRequestFormatRequestUsingCurrentType() before the send command. So
>>> > it has to do something with the Request object?
>>>
>>> > We tried to create a new request with WdfRequestCreateFromIrp() by
>>> > taking the original IRP with WdfRequestWdmGetIrp() but it doesn't seem
>>> > to create a new IRP, instead just copying a pointer to the old one
>>> > which causes a BSOD for exhausted stack.
>>>
>>> > So finally we got something working by creating a new IRP and poking
>>> > around with the stack location just as we would in WDM and creating a
>>> > WDF Request from that IRP - but it seems very odd that we have to work
>>> > on the WDM side even when we have this beautiful abstraction around
>>> > it. Now we have a hybrid of WDM inside WDF and completing request
>>> > correctly seems to be a nightmare - which still doesn't work...
>>>
>>> > So is Request delegation possible in WDF and if so, how?
>>
>>
>
>