[nik] Question on user space file open to driver

I took over a driver project and noticed that the user space application that access the driver opens and closes access to the driver every time it wants to send an IOCTL. Is this considered standard practice? I want to change the user space access to open a handle to the driver once, and close it when it exists… assuming it would be automatically closed if the user space app crashes?

Are there disadvantages to either of these methods? Or just balanced trade offs

Thanks,

Nik Twerdochlib
Software Developer

+1.601.607.8309 O
+1.866.522.8678 F

BOMGAR | The Box That’s Revolutionizing Remote Support™

One of the Fastest-Growing Technology Companies in America | Technology Fast 500™

If there is state associated with the open handle, not a good practice. If not stateful, this pattern is ok buy a bit wasteful in that you have 4 irps (create, ioctl, cleanup, close) for every ioctl

d

debt from my phone


From: Nik Twerdochlib
Sent: 8/28/2012 8:17 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] [nik] Question on user space file open to driver

I took over a driver project and noticed that the user space application that access the driver opens and closes access to the driver every time it wants to send an IOCTL. Is this considered standard practice? I want to change the user space access to open a handle to the driver once, and close it when it exists… assuming it would be automatically closed if the user space app crashes?

Are there disadvantages to either of these methods? Or just balanced trade offs

Thanks,

Nik Twerdochlib
Software Developer

+1.601.607.8309 O
+1.866.522.8678 F

BOMGAR | The Box That’s Revolutionizing Remote Support?

One of the Fastest-Growing Technology Companies in America | Technology Fast 500?


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

Part of it depends on what the IOCTL does. For example, the pattern

CreateFile WriteFile* CloseHandle

does not work reliably if the machine crashes, or even if the app crashes.
The pattern

{CreateFile SetFilePosition WriteFile CloseHandle}*

guarantees that the directory block is updated so the correct file size is
recorded, so if there is any catastrophe such as a power outage or system
crash, the file is intact up to the most recent update. Think of it as a
cheap simulation of a transacted file.

Historically, it sometimes happens that someone writes a subroutine of the
form

CreateFile DeviceIoControl CloseHandle

and does not realize the application will call it 100,000 times. So there
isn’t a lot of context to indicate exactly the purpose of the sequence: is
it an historical accident or is it a necessary part of the functionality?
See my essay on “The Bridge Color Problem”,
http://www.flounder.com/bridge.htm

joe

If there is state associated with the open handle, not a good practice. If
not stateful, this pattern is ok buy a bit wasteful in that you have 4
irps (create, ioctl, cleanup, close) for every ioctl

d

debt from my phone


From: Nik Twerdochlib
Sent: 8/28/2012 8:17 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] [nik] Question on user space file open to driver

I took over a driver project and noticed that the user space application
that access the driver opens and closes access to the driver every time it
wants to send an IOCTL. Is this considered standard practice? I want to
change the user space access to open a handle to the driver once, and
close it when it exists… assuming it would be automatically closed if the
user space app crashes?

Are there disadvantages to either of these methods? Or just balanced
trade offs

Thanks,

Nik Twerdochlib
Software Developer

+1.601.607.8309 O
+1.866.522.8678 F

BOMGAR | The Box That’s Revolutionizing Remote Support™

One of the Fastest-Growing Technology Companies in America | Technology
Fast 500™


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