hello,
I’m trying to Implimant Dma Transaction - READ from device through IOCTL
The problem is that In the process I should get 3 interrupts:
- first interrupt for write dma transaction for sending the read request .
- second interrupt for user interrupt that indicate to me that the hardware is ready continue to next step .
- third interrupt for read dma transaction.
The entire process seems to me not good and inaccurate if i will Implimant the process with more than one IOCTL from my application .
my goal is to send just one ioctl from application, and the whole process with interrupts until receiving the data from device will be done in the kernel.
To do this i want to implimant the process in the next stages:
- send from application ioctl code for read dma code.
- in the IoControl hendler i want to wait for event from dpc for each interrupt.
- After activation the write dma transaction (for read request) i want to wait for event (write dma interrupt) from dpc with timeout of course .
- If successful than the next step is to wait for the next event (user interrupt ) from dpc with timeout
- than i will activate the read dma transaction.
- wait for event (read dma interrupt) from dpc with timeout .
Is it possible to Implimant waitForEvent from dpc in IoControl Hendler??
If so, I would be glade if you could guide me how to do this
if not so , Please advise me on the right way to do this
Thanks,
mesi
Is it possible to Implimant waitForEvent from dpc in IoControl Hendler??
No, a DPC cannot wait on event. You need to pend the ioctl, return from the handler. Complete the ioctl when the last step is done or timeout occurs.
Please advise me on the right way to do this
The right way is to find someone to write the code and (optionally) explain to you how it works, and help you test it.
That means, hire a consultant.
– pa
No, a DPC cannot wait on event.
Actually, the way I understood the OP’s English, he is planning to wait in IOCTL handler and not in DPC.
OTOH, it is not so easy to understand what he is actually asking about - his technical skills and his level of English seem to be a close match to one another, so that helping him is, probably, not the easiest task one would imagine…
Anton Bassov
> @anton_bassov said: > No, a DPC cannot wait on event. > > > > > > Actually, the way I understood the OP’s English, he is planning to wait in IOCTL handler and not in DPC. > > OTOH, it is not so easy to understand what he is actually asking about - his technical skills and his level of English seem to be a close match to one another, so that helping him is, probably, not the easiest task one would imagine… > > Anton Bassov > @anton_bassov said: > No, a DPC cannot wait on event. > > > > > > Actually, the way I understood the OP’s English, he is planning to wait in IOCTL handler and not in DPC. > > OTOH, it is not so easy to understand what he is actually asking about - his technical skills and his level of English seem to be a close match to one another, so that helping him is, probably, not the easiest task one would imagine… > > Anton Bassov
I’ll try to explain myself again 
Is it possible to put a wait event in a ioctl driver code ? ** wait in IOCTL handler and not in DPC!!! for example the ioctl switch function : switch( cmd ) { … … case MY_IOCTL_1_CODE: … … wait_event(…); fired when the first interrupt occurs …or timeout # if timeout then finish request…and back to user space … … wait_event(…); fired when the second interrupt occurs …or timeout # if timeout then finish request…and back to user space … … wait_event(…); fired when the third interrupt occurs …or timeout # if timeout then finish request…and back to user space … … break; case MY_IOCTL_2_CODE: /* Any code that doesn’t block/wait */ break; … … } important points (i think…) i work with PCI device which supported MSI-X interrupt all interrupts using the same InterruptIsr, each interrupt is indicated by MessageId parameter . I Hope the question is more clear now sorry for my OP’s English mesi
Hi again Mesi,
Please read the last comment of Tim Roberts in this thread.
Technically, under some conditions it is possible to wait - but in 99% cases do not want this. My previous advice is your best, fastest, even cheapest option.
– pa
Is it possible to put a wait event in a ioctl driver code ?
Of course - as long as you signal the event from the DPC routine that your ISR has queued everything is going to work just fine…
However, please note that the calling thread is not going to return control to the userland code until all the waiting states/stages are passed.
If this is how you actually want things to work, then you can do it this way. Otherwise, you can do everything in context of a dedicated driver thread. You can make your IOCTL handler enqueue a request to it and return STATUS_PENDING straight away. When the request gets actually processed by this dedicated thread it will complete the original IRP…
Anton Bassov
Is it possible to put a wait event in a ioctl driver code ?
As a follow-up, it is (hopefully) understandable that my previous post concerning waiting in a handler applies only as long as you receive this IOCTL at IRQL<=APC_LEVEL. Otherwise, things very obviously cannot work this way, so that a dedicated thread or a workitem are the only possible options available…
Anton Bassov
On May 17, 2019, at 10:14 PM, mesi_gabay wrote:
>
> OSR https://community.osr.com/
> mesi_gabay commented on Wait for event from dpc in the IoControl hendler …Is it possible?
>
> I’ll try to explain myself again
> I Hope the question is more clear now
Your question was clear the first time. Were there parts of the answer that didn’t make sense to you?
> Is it possible to put a wait event in a ioctl driver code ?
Yes, it’s possible, but don’t do it. It’s not the right way to design a driver. It’s lazy coding. For one thing, it means applications calling your driver cannot use overlapped I/O, because you have stolen and blocked THEIR thread. I told you in detail exactly how you should do it in the last post.
> important points (i think…)
> i work with PCI device which supported MSI-X interrupt
> all interrupts using the same InterruptIsr,
> each interrupt is indicated by MessageId parameter .
None of that is really relevant to the design of your ioctl. It dictates the design of your ISR, but that’s about it.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
It’s not the right way to design a driver. It’s lazy coding. For one thing, it means applications calling your driver cannot use overlapped I/O, >because you have stolen and blocked THEIR thread
As long as we are speaking about a generic driver that is meant to interface a piece of hardware to different client apps the above statement is, certainly, 100% true.
However, in this particular case it seems to be a tightly-coupled driver-app pair so that the OP simply adjusts his driver to the needs of some particular app ( that, apparently, gets written by the OP as well)…
Anton Bassov
No, it’s always true. Because you might get away with it in a tightly coupled app-driver pair doesn’t make it “the right way to design a driver.”
Not to mention, assuming we’re talking KMDF, you don’t know WHAT thread your blocking.
Peter
No, it’s always true. Because you might get away with it in a tightly coupled app-driver pair doesn’t make it “the right way
to design a driver.”
You know, sometimes it is really funny to look back at the discussions we used to have 10 years ago, and to see how we have “flipped” our views since
https://community.osr.com/discussion/comment/157158
These days both you and Mr.Roberts seem to claim that adjusting drivers to the needs of poorly-written apps is always a bad idea.
At the same time, I had softened my stance a bit, and admit that, as long as a tightly-coupled app-driver pair serves its purposes well and makes users happy we can, probably, overlook its certain design flaws to some extent…
Anton Bassov
I know you’re bored, Mr. Bassov… but even you must see that adjusting the way a driver works to facilitate the implementation of a tightly-coupled app is not the same as implementing a bad driver design that will forever and needlessly constrain a tightly coupled app that is in no need of facilitation.
Two separate ideas.
Peter