I’m about to rewrite my miniport as a full port driver, unless someone can
offer a better solution…
The problem is very simple: most of the IOCTLs my driver needs to handle
contain in the data buffer a pointer to another arbitrarily allocated user
buffer. It’s sorta like a single indirection. Actually, I need to use the
primary data buffer (immediately following the SRB_IO_CONTROL struct) as a
proprietary struct, which has the “real” buffer as a pointer member. And
of course, I need to be able to move data in both directions inside the
IOCTL.
I can’t really start reallocating and copying things around since this
function of the driver must perform as well as possible.
I verified in the debugger that the current context was the process that
issued the IOCTL. Also I was able to see the user-level memory (it was
there just teasing me). But I’m in serious trouble as soon as an IOCTL is
issued after that buffer has been [partially] swapped out since I’m at
DIRQL. I should also mention that there isn’t really a size limit on the
buffer. In some cases it may be 16MB or so.
I am looking for any suggestions before I tackle a SCSI port replacement.
I would not even mind doing a layered driver if I need to. That actually
looks like a good compromise. In that situation I would need a way to
force the miniport to load prior to the upper layer, and I would need a way
for the upper layer driver to enumerate all of the cards managed by the
miniport.
Thanks again
Jason
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
There is a slight clarification below…
I’m about to rewrite my miniport as a full port driver, unless someone can
offer a better solution…
The problem is very simple: most of the IOCTLs my driver needs to handle
contain in the data buffer a pointer to another arbitrarily allocated user
buffer. It’s sorta like a single indirection. Actually, I need to use the
primary data buffer (immediately following the SRB_IO_CONTROL struct) as a
proprietary struct, which has the “real” buffer as a pointer member. And
of course, I need to be able to move data in both directions inside the
IOCTL.
I can’t really start reallocating and copying things around since this
function of the driver must perform as well as possible.
I verified in the debugger that the current context was the process that
issued the IOCTL. Also I was able to see the user-level memory (it was
there just teasing me). But I’m in serious trouble as soon as an IOCTL is
issued after that buffer has been [partially] swapped out since I’m at
DIRQL. I should also mention that there isn’t really a size limit on the
buffer. In some cases it may be 16MB or so.
I am looking for any suggestions before I tackle a SCSI port replacement.
–> I mean a replacement in the form of a SCSI port driver, to replace my
miniport, not to replace SCSIPORT 
I would not even mind doing a layered driver if I need to. That actually
looks like a good compromise. In that situation I would need a way to
force the miniport to load prior to the upper layer, and I would need a way
for the upper layer driver to enumerate all of the cards managed by the
miniport.
Thanks again
Jason
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> there just teasing me). But I’m in serious trouble as soon as an IOCTL is
issued after that buffer has been [partially] swapped out since I’m at
DIRQL. I should also mention that there isn’t really a size limit on the
buffer. In some cases it may be 16MB or so.
SCSIPORT will give you the process context guarantee at the miniport level. The reason is that SCSIPORT must queue SRBs, and the the
queue is consumed by some arbitrary DPCs, so, the process context is principally unknown in the miniport.
Max
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com