>> some reasons love it and keep it that way until introduction of iscsiprt and
> new storport.
I think msiscsi is storport’s virtual miniport.
So is storvsc (Hyper-V’s guest virtual SCSI).
IIRC iscsiprt.sys is an interim solution when storport was not able to
support virtual miniport. I don’t know if it has ever made it
to production. They merged back to storport later.
I guess they finally realized how cripple the SCSIPORT was and why outside programmers
need something better than the scsi miniport until
they have to support iscsi.
Yet they refused to back port storport to WXP which forces us who have
to battle with WXP support to mess with the scsiport. Yes, there are elegant
solutions but I feel sorry for burning raw intellengence
to deal with the nonsense and dying technology.
>It’s WAY WAY better than waiting for a timer tick to complete requests, don’t you think?
I missed that you compare this approach with timer completion.
The real unfortunate part about this is all microsoft had to do is a simple and transparent code change in a scsiport update that when it gets a RequestTimerCall with a delay value of 0 is to act on it immediately rather than waiting another 10ms. Would have saved about 100 discussion threads and who knows how many drivers. But the way it stands is the timer method is not a real solution and there is just no way that could ever be an acceptable product so just don’t go there. There are a number of efficient algorithms to get back on scsiport context, though some are lesser known and proprietary. I have seen a very elegant one not yet discussed.
Scsiport will continue to play a key role for future drivers as XP is the market today and forecasts say it will be a huge part of the market for years to come.