Re: NdisProt and multiple handles to the same device

Hi Thomas,

Thanks for the reply.

You are correct, I hadn't researched anync I/O fully. After having
reviewed the ReadFileEx documentation I was able to restructure my
application without having to change the driver.

Thanks,
Divya


Thomas F. Divine [DDK MVP] wrote:
NDISPROT uses this strategy to prevent multiple user-mode applications from
opening a handle to the adapter. This is the driver's way of enforcing
exclusing access.

Now this does NOT prevent your application from concurrently having a
pending read while also getting/setting OIDs at the same time. You can
concurrently do these operation on the ONE handle that your application
opens. You do NOT need to open multiple handles.

You could, for example, perform the read using asynchronous I/O. Perhaps
using ReadFileEx with a completion routine. The completion routine would be
called when the read completes. Even while the read is pending you could
perform OID requests on the same handle.

Considering changing the driver the way you are thinking suggests that you
may not have researched asynchronous I/O well enough yet. You should be able
to get the job done without having to change this aspect of your modified
and renamed NDISPROT driver.

Good luck,

Thomas F. Divine, Windows DDK MVP
http://www.rawether.net


"Divya" <rewire@xxxxxxxxx> wrote in message
news:1149795745.597955.161430@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi all,

Please bear with me as I'm not well versed with driver development.

I have to fulfill a requirement where I should be able to perform
read/write and getoid/setoid to an adapter at the same time. So say a
usermode thread is stuck in a sync read, I should still be able to set
oids.

Now the default ndisprot implementation prevents this by preventing
multiple file objects to be connected to the same ndis device. It
checks inside ndisprotOpenDevice of ntdisp.c that whether the
pOpenContext->pFileObject is not NULL, and if not, it fails with
STATUS_DEVICE_BUSY.

Now my question is, why does each context maintain the link back to the
file object. That is, why does pOpenContext have the pFileObject
member? What important perspective am I missing? Is this used for some
sort of reference counting?

How I plan to achieve my solution is by removing the checks for exising
pFileObject in ndisprotOpenDevice, this way IOCTL_NDISPROT_OPEN_DEVICE
would succeed even if a device is already open with another file
object. Then I can open two handles to the device, use one for
read/write and another for getoid/setoid.

Does this seem correct? Is changing the driver appropriate or should I
change the architecture or my application?

Please enlighten me,

Thanks,
Divya


.

Relevant Pages

  • Re: NdisProt and multiple handles to the same device
    ... NDISPROT uses this strategy to prevent multiple user-mode applications from opening a handle to the adapter. ... You can concurrently do these operation on the ONE handle that your application opens. ... Considering changing the driver the way you are thinking suggests that you may not have researched asynchronous I/O well enough yet. ... You should be able to get the job done without having to change this aspect of your modified and renamed NDISPROT driver. ...
    (microsoft.public.development.device.drivers)
  • [PATCH 19-rc1] Fix typos in /Documentation : U-Z
    ... when the underlying device was capable of handling the i/o in one shot. ... using dev->irq by the device driver to request for interrupt service ... The EMU10K2 chips have a DSP part which can be programmed to support ... -(This acticle does not deal with the overall functionality of the ...
    (Linux-Kernel)
  • Re: [PATCH 19-rc1] Fix typos in /Documentation : U-Z
    ... +iii.Ability to represent large i/os w/o unnecessarily breaking them up (i.e ... when the underlying device was capable of handling the i/o in one shot. ... using dev->irq by the device driver to request for interrupt service ... -(This acticle does not deal with the overall functionality of the ...
    (Linux-Kernel)
  • [PATCH 18-rc3] Fix typos in /Documentation : S
    ... Request flows seen by I/O schedulers ... cpufreq-stats is a driver that provices CPU frequency statistics for each CPU. ... +interface will appear in a separate directory under cpufreq ... This drives supports all SMC ISA/MCA adapters. ...
    (Linux-Kernel)
  • Re: vgone() calling VOP_CLOSE() -> blocked threads?
    ... d_closeis called on a TTY, ... because revoke() isn't normally applied to any devices except ttys. ... The tty driver is about the only driver that handles this problem ... opens are allowed, and this is useful for doing ioctlsto unblocked ...
    (freebsd-arch)
Loading