It seems that TRIM/UNMAP is not supported for storport drivers in Windows 7/2008R2. From reading past threads on ntdev and other forums, the ways that I might achieve this functionality are to create a disk filter driver and pass through the discard IOCTL to my storport driver as an UNMAP SRB, or to use the ataport driver.
From a read of the docs on ataport, I think I could create a virtual ataport driver, assuming the following are true:
. no restriction exists on calling AtaXxx functions from “outside” the ataport context. I remember this being a limitation of scsiport where you basically had to kick off requests from a timer or an interrupt. You couldn’t queue a Dpc from somewhere else and then start calling scsiport routines
. all buffers can be mapped. The docs say I can set IRB_FLAGS_MAP_BUFFERS in my BuildIo routine to get ataport to map the buffers before the call to StartIo so unless there are any restrictions there this should work. Dump mode might be a problem though.
. no requirement for hardware resources to even exist. This was a bug/feature of scsiport where if no actual hardware resources existed the driver couldn’t start so you had to fake some via a bus driver or an upper filter
Any comments on which might be better… a filter or a virtual ataport?
Thanks
James
On 4 October 2012 22:56, James Harper wrote:
> It seems that TRIM/UNMAP is not supported for storport drivers in Windows 7/2008R2. From reading past threads on ntdev and other forums, the ways that I might achieve this functionality are to create a disk filter driver and pass through the discard IOCTL to my storport driver as an UNMAP SRB, or to use the ataport driver.
>
> From a read of the docs on ataport, I think I could create a virtual ataport driver, assuming the following are true:
> . no restriction exists on calling AtaXxx functions from “outside” the ataport context. I remember this being a limitation of scsiport where you basically had to kick off requests from a timer or an interrupt. You couldn’t queue a Dpc from somewhere else and then start calling scsiport routines
> . all buffers can be mapped. The docs say I can set IRB_FLAGS_MAP_BUFFERS in my BuildIo routine to get ataport to map the buffers before the call to StartIo so unless there are any restrictions there this should work. Dump mode might be a problem though.
> . no requirement for hardware resources to even exist. This was a bug/feature of scsiport where if no actual hardware resources existed the driver couldn’t start so you had to fake some via a bus driver or an upper filter
>
Adding a filter, either as an upper filter to your storport driver, or
as a lover filter to the disk class is almost certainly going to be a
simpler solution. I think developing an ataport driver would be brave
Paul
–
Paul Durrant
http://www.linkedin.com/in/pdurrant
Paul Durrant wrote:
Adding a filter, either as an upper filter to your storport driver, or
as a lover filter to the disk class is almost certainly going to be a
simpler solution.
As typos go, “lover filter” has to be one of my favorites.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.