If a driver implements both FastIoDeviceControl and IRP_MJ_DEVICE_CONTROL which entry point will be called.
…Mani
> If a driver implements both FastIoDeviceControl
and IRP_MJ_DEVICE_CONTROL which entry point will be called.
AFAIK if an application calls DeviceIoControl API,
the object manager calls the FastIo first. If this call
returns FALSE, then the IRP is called.
On the other side, an upper driver above yours might
decide to call the IRP only.
L.
To the best of my knowledge this is exact as Ladislav has described. Your driver has to accept ioctl on both interfaces.
“Mani” wrote in message news:xxxxx@ntfsd…
If a driver implements both FastIoDeviceControl and IRP_MJ_DEVICE_CONTROL which entry point will be called.
…Mani
FastIo first, then the IRP if the FastIo will return FALSE.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Mani
Newsgroups: ntfsd
To: Windows File Systems Devs Interest List
Sent: Thursday, May 26, 2005 11:15 AM
Subject: [ntfsd] FastIoDeviceControl Vs IRP_MJ_DEVICE_CONTROL
If a driver implements both FastIoDeviceControl and IRP_MJ_DEVICE_CONTROL which entry point will be called.
…Mani
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
I strongly recommend returning FALSE to FastIoDeviceIoControl and only
implementing the IRP interface. Buffers are completely raw in the FastIo
method regardless of the real METHOD of the IOCTL. So if you are
implementing the fast i/o method, you need to probe the buffer and
try-except() wrap accesses to the buffer. But then catching exceptions
other than just accesses to the buffer will result in you catching
exceptions you are not supposed to catch.
To get this right will require really careful coding - I’ve seen a lot
of bugs in this area. So just return FALSE for fast i/o dispatch, unless
you are already using METHOD_NEITHER in which case you have to do all of
the above anyway. Perf wise it doesn’t make any difference.
Ravi
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, May 26, 2005 5:31 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FastIoDeviceControl Vs IRP_MJ_DEVICE_CONTROL
FastIo first, then the IRP if the FastIo will return FALSE.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Mani mailto:xxxxx
Newsgroups: ntfsd
To: Windows File Systems Devs Interest List
mailto:xxxxx
Sent: Thursday, May 26, 2005 11:15 AM
Subject: [ntfsd] FastIoDeviceControl Vs IRP_MJ_DEVICE_CONTROL
If a driver implements both FastIoDeviceControl and
IRP_MJ_DEVICE_CONTROL which entry point will be called.
…Mani
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com mailto:xxxxx
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
And one additional note: if you DO implement the fast I/O path, remember
you must also implement the IRP path, in case a filter above you rejects
the fast I/O path. Fast I/O is OPTIONAL, IRP_MJ is required.
I strongly agree with Ravi on the point that it doesn’t make much sense
to use the fast I/O device control path, and it is very easy to get it
wrong - I’ve seen this in shipping code more than once.
I hate to sound like a broken record here, but just because it is CALLED
“fast I/O” you shouldn’t automatically assume that this means it is
“fast”.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ravisankar Pudipeddi
Sent: Thursday, May 26, 2005 2:15 PM
To: ntfsd redirect
Subject: RE: [ntfsd] FastIoDeviceControl Vs IRP_MJ_DEVICE_CONTROL
I strongly recommend returning FALSE to FastIoDeviceIoControl and only
implementing the IRP interface. Buffers are completely raw in the FastIo
method regardless of the real METHOD of the IOCTL. So if you are
implementing the fast i/o method, you need to probe the buffer and
try-except() wrap accesses to the buffer. But then catching exceptions
other than just accesses to the buffer will result in you catching
exceptions you are not supposed to catch.
To get this right will require really careful coding - I’ve seen a lot
of bugs in this area. So just return FALSE for fast i/o dispatch, unless
you are already using METHOD_NEITHER in which case you have to do all of
the above anyway. Perf wise it doesn’t make any difference.
Ravi
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, May 26, 2005 5:31 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FastIoDeviceControl Vs IRP_MJ_DEVICE_CONTROL
FastIo first, then the IRP if the FastIo will return FALSE.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Mani mailto:xxxxx
Newsgroups: ntfsd
To: Windows File Systems Devs Interest List
mailto:xxxxx
Sent: Thursday, May 26, 2005 11:15 AM
Subject: [ntfsd] FastIoDeviceControl Vs IRP_MJ_DEVICE_CONTROL
If a driver implements both FastIoDeviceControl and
IRP_MJ_DEVICE_CONTROL which entry point will be called.
…Mani
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com mailto:xxxxx
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com —
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
So as a FSF can i skip the Fast IO implementation. i think if i skip it i will be called on IRP path.
“Tony Mason” wrote in message news:xxxxx@ntfsd…
And one additional note: if you DO implement the fast I/O path, remember you must also implement the IRP path, in case a filter above you rejects the fast I/O path. Fast I/O is OPTIONAL, IRP_MJ is required.
I strongly agree with Ravi on the point that it doesn’t make much sense to use the fast I/O device control path, and it is very easy to get it wrong - I’ve seen this in shipping code more than once.
I hate to sound like a broken record here, but just because it is CALLED “fast I/O” you shouldn’t automatically assume that this means it is “fast”.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
------------------------------------------------------------------------------
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ravisankar Pudipeddi
Sent: Thursday, May 26, 2005 2:15 PM
To: ntfsd redirect
Subject: RE: [ntfsd] FastIoDeviceControl Vs IRP_MJ_DEVICE_CONTROL
I strongly recommend returning FALSE to FastIoDeviceIoControl and only implementing the IRP interface. Buffers are completely raw in the FastIo method regardless of the real METHOD of the IOCTL. So if you are implementing the fast i/o method, you need to probe the buffer and try-except() wrap accesses to the buffer. But then catching exceptions other than just accesses to the buffer will result in you catching exceptions you are not supposed to catch.
To get this right will require really careful coding - I’ve seen a lot of bugs in this area. So just return FALSE for fast i/o dispatch, unless you are already using METHOD_NEITHER in which case you have to do all of the above anyway. Perf wise it doesn’t make any difference.
Ravi
------------------------------------------------------------------------------
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, May 26, 2005 5:31 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FastIoDeviceControl Vs IRP_MJ_DEVICE_CONTROL
FastIo first, then the IRP if the FastIo will return FALSE.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Mani
Newsgroups: ntfsd
To: Windows File Systems Devs Interest List
Sent: Thursday, May 26, 2005 11:15 AM
Subject: [ntfsd] FastIoDeviceControl Vs IRP_MJ_DEVICE_CONTROL
If a driver implements both FastIoDeviceControl and IRP_MJ_DEVICE_CONTROL which entry point will be called.
…Mani
—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com —
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
As a filter if you skip implementing this fast I/O routine, the I/O
manager will just call it in the base file system. A filter must
implement all of the entry points implemented by its file systems. If
you want it as an irp, implement the fast I/O routine and when it is
called return FALSE - that will cause it to come down the IRP path.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mani
Sent: Friday, May 27, 2005 2:34 AM
To: ntfsd redirect
Subject: Re:[ntfsd] FastIoDeviceControl Vs IRP_MJ_DEVICE_CONTROL
So as a FSF can i skip the Fast IO implementation. i think if i skip it
i will be called on IRP path.
“Tony Mason” wrote in message
news:xxxxx@ntfsd…
And one additional note: if you DO implement the fast I/O path,
remember you must also implement the IRP path, in case a filter above
you rejects the fast I/O path. Fast I/O is OPTIONAL, IRP_MJ is
required.
I strongly agree with Ravi on the point that it doesn’t make
much sense to use the fast I/O device control path, and it is very easy
to get it wrong - I’ve seen this in shipping code more than once.
I hate to sound like a broken record here, but just because it
is CALLED “fast I/O” you shouldn’t automatically assume that this means
it is “fast”.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ravisankar Pudipeddi
Sent: Thursday, May 26, 2005 2:15 PM
To: ntfsd redirect
Subject: RE: [ntfsd] FastIoDeviceControl Vs
IRP_MJ_DEVICE_CONTROL
I strongly recommend returning FALSE to FastIoDeviceIoControl
and only implementing the IRP interface. Buffers are completely raw in
the FastIo method regardless of the real METHOD of the IOCTL. So if you
are implementing the fast i/o method, you need to probe the buffer and
try-except() wrap accesses to the buffer. But then catching exceptions
other than just accesses to the buffer will result in you catching
exceptions you are not supposed to catch.
To get this right will require really careful coding - I’ve seen
a lot of bugs in this area. So just return FALSE for fast i/o dispatch,
unless you are already using METHOD_NEITHER in which case you have to do
all of the above anyway. Perf wise it doesn’t make any difference.
Ravi
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, May 26, 2005 5:31 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FastIoDeviceControl Vs
IRP_MJ_DEVICE_CONTROL
FastIo first, then the IRP if the FastIo will return FALSE.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Mani mailto:xxxxx
Newsgroups: ntfsd
To: Windows File Systems Devs Interest List
mailto:xxxxx
Sent: Thursday, May 26, 2005 11:15 AM
Subject: [ntfsd] FastIoDeviceControl Vs
IRP_MJ_DEVICE_CONTROL
If a driver implements both FastIoDeviceControl and
IRP_MJ_DEVICE_CONTROL which entry point will be called.
…Mani
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown
lmsubst tag argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com mailto:xxxxx
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com —
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
Ok, to confirm:
if the FSD skips the FastIO it will be invoked on IRP path, if filter skips the FastIO it won’t be invoked on IRP. Instead directly the base file systems FastIO (if implemented) will be called, and if again the FSD doesn’t implements the FastIO, the filter will get it via IRP path.
“Tony Mason” wrote in message news:xxxxx@ntfsd…
As a filter if you skip implementing this fast I/O routine, the I/O manager will just call it in the base file system. A filter must implement all of the entry points implemented by its file systems. If you want it as an irp, implement the fast I/O routine and when it is called return FALSE - that will cause it to come down the IRP path.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
------------------------------------------------------------------------------
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mani
Sent: Friday, May 27, 2005 2:34 AM
To: ntfsd redirect
Subject: Re:[ntfsd] FastIoDeviceControl Vs IRP_MJ_DEVICE_CONTROL
So as a FSF can i skip the Fast IO implementation. i think if i skip it i will be called on IRP path.
“Tony Mason” wrote in message news:xxxxx@ntfsd…
And one additional note: if you DO implement the fast I/O path, remember you must also implement the IRP path, in case a filter above you rejects the fast I/O path. Fast I/O is OPTIONAL, IRP_MJ is required.
I strongly agree with Ravi on the point that it doesn’t make much sense to use the fast I/O device control path, and it is very easy to get it wrong - I’ve seen this in shipping code more than once.
I hate to sound like a broken record here, but just because it is CALLED “fast I/O” you shouldn’t automatically assume that this means it is “fast”.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
----------------------------------------------------------------------------
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ravisankar Pudipeddi
Sent: Thursday, May 26, 2005 2:15 PM
To: ntfsd redirect
Subject: RE: [ntfsd] FastIoDeviceControl Vs IRP_MJ_DEVICE_CONTROL
I strongly recommend returning FALSE to FastIoDeviceIoControl and only implementing the IRP interface. Buffers are completely raw in the FastIo method regardless of the real METHOD of the IOCTL. So if you are implementing the fast i/o method, you need to probe the buffer and try-except() wrap accesses to the buffer. But then catching exceptions other than just accesses to the buffer will result in you catching exceptions you are not supposed to catch.
To get this right will require really careful coding - I’ve seen a lot of bugs in this area. So just return FALSE for fast i/o dispatch, unless you are already using METHOD_NEITHER in which case you have to do all of the above anyway. Perf wise it doesn’t make any difference.
Ravi
----------------------------------------------------------------------------
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, May 26, 2005 5:31 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FastIoDeviceControl Vs IRP_MJ_DEVICE_CONTROL
FastIo first, then the IRP if the FastIo will return FALSE.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Mani
Newsgroups: ntfsd
To: Windows File Systems Devs Interest List
Sent: Thursday, May 26, 2005 11:15 AM
Subject: [ntfsd] FastIoDeviceControl Vs IRP_MJ_DEVICE_CONTROL
If a driver implements both FastIoDeviceControl and IRP_MJ_DEVICE_CONTROL which entry point will be called.
…Mani
—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com —
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com