reading a file in IRQL=DISPATCH_LEVEL
Hans de Bruijn
Can I use CreateFile in my ISR (IRQL=DISPATCH_LEVEL) to load the contents of
a file??
if yes what headerfile should i include (stdio.h)?
and what library should i link??
ZwCreateFile is not allowed in IRQL=DISPATCH_LEVEL.
thanks for helping me
Hans de Bruijn
Walter Oney
> Can I use CreateFile in my ISR (IRQL=DISPATCH_LEVEL) to load the contents of
> a file??
> if yes what headerfile should i include (stdio.h)?
> and what library should i link??
> ZwCreateFile is not allowed in IRQL=DISPATCH_LEVEL.
I think you're missing a couple of important things here. Your ISR runs
at an IRQL higher than DISPATCH_LEVEL for starters. In addition, and
more basically, kernel-mode drivers do not have any access whatever to
user-mode API's like CreateFile. In fact, CreateFile is implemented by
calling NtCreateFile. ZwCreateFile is *also* implemented by calling
NtCreateFile. You simply can't do what you want to do, so you have to
design around the limitations of the system.
--
Walter Oney
Consulting and Training
http://www.oneysoft.com
Hans de Bruijn
I don't know if the code is in a ISR, but i know it is in
IRQL=DISPATCH_LEVEL.
I used KeGetCurrentIrql to check this.
It is in the function ImageSynth (capxfer.c) of the TestCap sample
device-driver that i want to read a file from harddisc.
Is there any way i can do this??
"Walter Oney" <walt...@oneysoft.com> wrote in message
news:3CD83D2...@oneysoft.com...
Walter Oney
> I don't know if the code is in a ISR, but i know it is in
> IRQL=DISPATCH_LEVEL.
> I used KeGetCurrentIrql to check this.
> It is in the function ImageSynth (capxfer.c) of the TestCap sample
> device-driver that i want to read a file from harddisc.
> Is there any way i can do this??
In a word, no. You can, however, schedule a workitem callback, which
would happen at PASSIVE_LEVEL in a system thread. You can do all the
reads and writes you want at that point.
Bill McKenzie
its behalf. An exception would be maybe something like a firmware file.
Why do you want to read the file, as in what are you attempting to
accomplish?
--
Bill McKenzie
"Hans de Bruijn" <h.de....@home.nl> wrote in message
news:urg0wpf9BHA.2568@tkmsftngp07...
Hans de Bruijn
I want to read bitmaps from harddisc and display them as frames like a
webcam.
I have it working by reading 1 bitmap that contains several images. I read
this bitmap to memory using ZwCreateFile in the HwInitilize routine. This
works fine if i want to display a few images but not for displaying, let's
say, 1000 images. because each image takes up 226000 bytes of memory. So I
thought i could use the same ZwCreateFile in the frame-processing function,
which is executed at IRQL=DISPATCH_LEVEL, to read the bitmap that i want to
display, but that doesn't work (bugcheck).
Any idea to solve this??
Hans de Bruijn
"Bill McKenzie" <bmck...@driver.attbbs.com> wrote in message
news:#4FHSWp9BHA.1656@tkmsftngp07...
Bill McKenzie
can't see it at the moment.
--
Bill McKenzie
"Hans de Bruijn" <h.de....@home.nl> wrote in message
news:ew7p9Sr9BHA.2636@tkmsftngp05...
Hans de Bruijn
I use a device-driver because i want to make a software-webcam. A hardware
webcam uses a device driver so programs like netmeeting, icuii, webcam32
etc. can display the images comming from the webcam.
The device-driver i'm working on loads the images from file(s) instead of
retreiving them from a real (usb)webcam.
I have a working version but it has some restrictions recarding the number
of images that can be displayed because all images are loaded into memery at
driver initialisation.
If you know about a better way to accomplish this, please let me know
Hans de Bruijn
"Bill McKenzie" <bmck...@driver.attbbs.com> wrote in message
news:#180tsr9BHA.1724@tkmsftngp03...
Bill McKenzie
whatever, I get it. So are there still as yet unanswered questions?
Walter's suggestion of a work item to get to PASSIVE_LEVEL is the usual way
from DISPATCH_LEVEL.
--
Bill McKenzie
"Hans de Bruijn" <h.de....@home.nl> wrote in message
news:#Lrl0ls9BHA.1724@tkmsftngp03...
Arnaud G.
Well, I think that you can avoid all the complicated code because it seems
to me that there is no reason why the frame-processing function should be
called at DISPATCH_LEVEL.
The typical mistake that people make is to let the class driver do the
synchronization... The synchronization scheme is brutal because they use a
spinlock (or even an interrupt spinlock (KeSynchronizeExecution) when you
have an ISR)... This indeed raises the IRQL to DISPATCH_LEVEL (or DIRQL if
you have an ISR). So what you want to do is to set the
TurnOffSynchronization flag to TRUE in the HW_INITIALIZATION_DATA structure
passed during your call to StreamClassRegisterMinidriver.
With the synchronization turned off you will receive SRBs at PASSIVE_LEVEL.
You will still have to worry about synchronizing your queues and various
driver resources but since you have no hardware to deal with (so no ISR and
no need for any hardware related DPCs or things of the sort which would
elevate the IRQL in your code) Mutexes will do the trick (you should be able
to avoid spinlocks). This will keep your code running at PASSIVE_LEVEL (or
APC_LEVEL) and as such you will be able to call ZwCreateFile and
ZwReadFile...
If you are using DPC timers to time your frames, then have the DPCs schedule
a CriticalWorkQueue work item, or better, do not use DPC timers but instead
have a RealTime kernel thread (priority 24) wait on the timer object. The
latency and latency jitter should be reasonable with the real time kernel
thread... Also if you make up the frame timestamps to match the required
frame rate (which is OK here since the images are coming from a pre-recorded
file which you assume is at the correct rate), you will absorb the
scheduling jitter...
So anyway, the point is, that in your case I would try to not be at
DISPATCH_LEVEL (I don't know your exact requirements but it should be
possible) rather than trying to figure a way when already at
DISPATCH_LEVEL...
Hope this helps,
Arnaud.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Arnaud Glatron
ZMagic Corporation
Your solution to system software on Windows
We do Magic so that you succeed!
Sunnyvale, CA
USA
Web: http://www.ZMagicCorp.com
Find more tips at: http://www.zmagiccorp.com/Tips_and_tricks.htm
"Hans de Bruijn" <h.de....@home.nl> wrote in message
news:ew7p9Sr9BHA.2636@tkmsftngp05...
Walter Oney
> <snip> Mutexes will do the trick (you should be able
> to avoid spinlocks). This will keep your code running at PASSIVE_LEVEL (or
> APC_LEVEL) and as such you will be able to call ZwCreateFile and
> ZwReadFile...
Don't call ZwCreateFile or ZwReadFile at APC_LEVEL. The reason the DDK
says these are PASSIVE_LEVEL only is that the system uses a special
kernel APC to finish the completion process. Calling them at APC_LEVEL
leads to a deadlocked thread. Therefore, don't use an executive fast
mutex for synchronization in a case like this. Use a regular mutex, or
else call KeEnterCriticalRegion following by ExAcquireFastMutexUnsafe.
Don't rely simply on a synchronization event (without a critical region)
because that allows user-mode code to create a deadlock by suspending
the thread.
Hans de Bruijn
Here is some of the code I use.
It is the code from the DDK sample TestCap:
in DriverEntry:
HwInitData.HwReceivePacket = AdapterReceivePacket;
HwInitData.TurnOffSynchronization = TRUE;
StreamClassRegisterAdapter(DriverObject, RegistryPath, &HwInitData);
in AdapterReceivePacket:
switch (pSrb->Command)
{
case SRB_OPEN_STREAM:
// open a stream
AdapterOpenStream(pSrb);
}
In AdapterOpenStream:
pSrb->StreamObject->ReceiveControlPacket =
(PVOID)
Streams[StreamNumber].hwStreamObject.ReceiveControlPacket;
(PVOID) Streams[StreamNumber].hwStreamObject.ReceiveControlPacket =
VideoReceiveCtrlPacket(pSrb):
In VideoReceiveCtrlPacket(pSrb):
switch (pSrb->Command)
{
case SRB_SET_STREAM_STATE:
VideoSetState(pSrb);
break;
}
The sub VideoSetState sets a callback to the frameprocessing routine
ideoTimerRoutine' with this function:
StreamClassScheduleTimer (
pSrb->StreamObject, //
StreamObject
pHwDevExt, //
HwDeviceExtension
(ULONG) (pStrmEx->AvgTimePerFrame / 20), //
Microseconds
VideoTimerRoutine, //
TimerRoutine
pStrmEx); //
Context
The callback fucntion VideoTimerRoutine is executed at IRQL=DISPATCH_LEVEL
so it cannot use ZwCreateFile to load an image from harddisk.
How can I have the callback being executed at IRQL=PASSIVE_LEVEL??? or is
there another solution?
thanks for your help
Hans de Bruijn
"Arnaud G." <Arn...@NoSpamArnaudG.com> wrote in message
news:#uecYdw9BHA.2644@tkmsftngp03...
Arnaud G.
I guess my sentence was not very explicit and even confusing. What I meant
was that depending on which sort of synchronization object he was using he
could end up at APC_LEVEL (which most people don't realize). I fully agree
with you that ZWCreateFile and ZwReadFile should only be called from
PASSIVE_LEVEL.
I originally did not mention APC_LEVEL in this post, and then I realized he
might want to use something else than a mutex and might end up at APC_LEVEL,
so I added this little insert... That will teach not to add stuff in a post
just before sending it... :)
Sorry if I was confusing,
Arnaud.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Arnaud Glatron
ZMagic Corporation
Your solution to system software on Windows
We do Magic so that you succeed!
Sunnyvale, CA
USA
Web: http://www.ZMagicCorp.com
Find more tips at: http://www.zmagiccorp.com/Tips_and_tricks.htm
"Walter Oney" <walt...@oneysoft.com> wrote in message
news:3CDA3B9C...@oneysoft.com...
Arnaud G.
don't have all of the pieces in hand so this advice should only be taken as
a quick suggestion), is setup a realtime kernel thread (priority 24, 16
might be enough: you should experiment a bit with the scheduling latency and
the latency jitter) and have this thread wait on a timer kernel object that
you setup with KeInitializeTimerEx (type:SynchronizationTimer) and start
with KeSetTimerEx (setup the period with the period corresponding to your
frame rate. Watch for the units of time...). This way your thread will run
at regular intervals. This thread can then create one frame and then loop
back to start waiting for the timer again... As I said in my previous post,
by artificially generating the timestamps to match the requested rate you
can absorb most of the latency jitter. Also if you see that there is drift
because of accumulated latency, you could use a one shot timer (instead of a
periodic one) that you would re-arm each time with a delay that tries to
match the time remaining to the next theoretical frame event (remember to
use the stream clock to get the time)... The exact algorithm you choose will
have to come from experiments and experience...
You could also use work items that you would schedule each time a timer
callback occurs, but I would be in favor of creating your own thread in this
particular case. The only thing will be to determine the appropriate
priority to get the best balance between system resources usage and
functionality. Don't be to close from the edge though as each system can
behave differently.
Regards,
Arnaud.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Arnaud Glatron
ZMagic Corporation
Your solution to system software on Windows
We do Magic so that you succeed!
Sunnyvale, CA
USA
Web: http://www.ZMagicCorp.com
Find more tips at: http://www.zmagiccorp.com/Tips_and_tricks.htm
"Hans de Bruijn" <h.de....@home.nl> wrote in message
news:Ovr0aL19BHA.2612@tkmsftngp07...
<snipped>
Hans de Bruijn
Hi,
I found a function to goto PASSIVE_LEVEL
The function is StreamClassCallAtNewPriority
One of the parameters is a functionadres, this function will be executed at
a desired level
In this function i can use ZwCreateFile to read the image.
It works fine!!
any comment is welcome.
thanks for helping me
Hans de Bruijn
"Hans de Bruijn" <h.de....@home.nl> wrote in message
news:urg0wpf9BHA.2568@tkmsftngp07...
Arnaud G.
This will work but I don't believe this will give you as good of a result as
creating your own 'image providing' thread. The main issue here is to
control latency (especially jitter) and calling
'StreamClassCallAtNewPriority' (which very likely schedules a work item to
go to PASSIVE_LEVEL) will not be as precise IMHO. For example, if another
driver is making a heavy usage of workitems your callback could be delayed
until a thread is available in the pool of workitem threads... This is
especially true on Win9x platforms where the number of work item threads is
very limited.
Arnaud.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Arnaud Glatron
ZMagic Corporation
Your solution to system software on Windows
We do Magic so that you succeed!
Sunnyvale, CA
USA
Web: http://www.ZMagicCorp.com
Find more tips at: http://www.zmagiccorp.com/Tips_and_tricks.htm
"Hans de Bruijn" <h.de....@home.nl> wrote in message
news:ei6o9k59BHA.2620@tkmsftngp05...
Hans de Bruijn
I don't think the routine at lower priority is delayed but executed
immediately.
I can see this if i look at the debug messages i generate just before i call
'StreamClassCallAtNewPriority' , in the routine and after the call to
'StreamClassCallAtNewPriority'
They are in the right order.
Thank for helping me
Hans de Bruijn
"Arnaud G." <Arn...@NoSpamArnaudG.com> wrote in message
news:us2bPy59BHA.2684@tkmsftngp03...