I am novice in this area, so please excuse me for dumb question.
Is there a way to communicate between one storport miniport to another storport miniport driver?
Such as - if one storport miniport driver (say mp1) implements RAID logic (only), but it wants to use inbox miniport driver storahci.sys (say mp2) to communicate to the underlying disks.
I have gone through Virtual miniport article (http://www.osronline.com/article.cfm?article=538). If my understanding is correct, the above looks to be possible if I make mp1 as virtual storport miniport.
Am I correct?
If I get it correctly, in the said article mp1 has to initiate IRP to communicate to mp2, which involves data copying and again the I/O has to travel from class driver to mp2 (storahci.sys). This will have performance impact.
Or I have got all wrong 
As we so frequently say in this forum “Please explain to us what end goal you are trying to achieve, and then we can tell you how to best get to that goal, instead of assuming a particular solution you’ve chosen is a good one, and asking us how to make that work.”
But… you can certainly send IRPs from one mini-port driver (your virtual mini-port that surfaces a disk drive and implements RAID, for example) to another mini-port driver (that actually talks to hardware). You are correct that do this via IRPs. But that does not involve copying any data.
Class -> MP1 -> MP2
Peter
OSR
@OSRDrivers
Or:
–> MP1
Class – Filter --|
–> MP2
It really depends on what you are trying to achieve.
ᐧ
On Thu, May 21, 2015 at 9:41 AM, wrote:
> As we so frequently say in this forum “Please explain to us what end goal
> you are trying to achieve, and then we can tell you how to best get to that
> goal, instead of assuming a particular solution you’ve chosen is a good
> one, and asking us how to make that work.”
>
> But… you can certainly send IRPs from one mini-port driver (your virtual
> mini-port that surfaces a disk drive and implements RAID, for example) to
> another mini-port driver (that actually talks to hardware). You are
> correct that do this via IRPs. But that does not involve copying any data.
>
> Class -> MP1 -> MP2
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Jamey Kirby
Disrupting the establishment since 1964
This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.
This is what Storage Spaces do.
Yes, you can.
The most serios issue is how to hide the physical disk dedicated to Miniport 2 from usual disk mgmt.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
>I am novice in this area, so please excuse me for dumb question.
>
> Is there a way to communicate between one storport miniport to another storport miniport driver?
> Such as - if one storport miniport driver (say mp1) implements RAID logic (only), but it wants to use inbox miniport driver storahci.sys (say mp2) to communicate to the underlying disks.
>
> I have gone through Virtual miniport article (http://www.osronline.com/article.cfm?article=538). If my understanding is correct, the above looks to be possible if I make mp1 as virtual storport miniport.
> Am I correct?
> If I get it correctly, in the said article mp1 has to initiate IRP to communicate to mp2, which involves data copying and again the I/O has to travel from class driver to mp2 (storahci.sys). This will have performance impact.
> Or I have got all wrong
>
>
Thanks Peter, James and Maxim for your reply.
@Peter/Jamey - I accept the comment and try to put my end goal. Kindly let me know if I am not clear:
I would like to have RAID logic in any one of the layers in driver stack which should be able to use inbox drivers for actual physical access to drives, such as AHCI drive, PCI device or USB device. In this way I would be only concerned with RAID logic implementation.
=> Class -> MP1 -> MP2
=> –> MP1
Class –> Filter –>|
–> MP2
My understanding was if I create IRP from MP1 (as part of parent IRP processing based on RAID level), it will go back to class driver (and lower filter driver) and then routed to MP2 (inbox driver).
Are you suggesting we can directly talk to MP2 from MP1? Or it is implied that class will come in between when you say MP1 -> MP2 (sorry, I am a newbie)?
@Maxim - So, is Storage Space a Virtual Storport Miniport?
And yes, I have not considered how can I hide physical disk from disk manager and stop getting it managed from there. It might cause contradicting/overlapping commands to disk and make it of no use (associated VD would vanish). Not sure how to protect it? Any idea?
> @Maxim - So, is Storage Space a Virtual Storport Miniport?
It is a miniport for sure, I’m not 100% sure it is a Virtual Storport Miniport, but I’m 99% sure of it 
Also, iSCSI client and STORVSC (guest emulated SCSI driver for Hyper-V) are Virtual Storport Miniports. 100%. That’s why there is no guest SCSI for XP guests (XP 32bit has no StorPort).
And yes, I have not considered how can I hide physical disk from disk manager and stop getting it
managed from there.
Look at how Storage Spaces do this. I don’t know
Probably they replace disk.sys with some other driver (I think MPIO was once doing this trick), or attach a lower filter there.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks Maxim, let me peep into storage space driver
Thanks Maxim … let me peep into storage space
If you write the bus filter driver (filters each storage controller and attaches its own devnodes to the child LUN PDOs in MN_QUERY_RELATIONS path, then manages their lifetimes), then you can filter QUERY_ID on disks.
In the filter, remove “GenDisk” ID (and probably some more IDs) to disallow disk.sys on this devnode. Instead, create a hidden (also filter “query capabilities”) devnode with your own IDs, which will be serviced by your driver (same bus filter or a second binary), with your own naming and PnP devinterface GUIDs.
Then the rest of your code senses these “special disk” devices (which can be targets of SCSI SRBs still) and use them as physical disks for your RAID.
The power policy owner for disks is implemented in a PDO (StorPort), so you do not need this piece of code. Just respond to Dx IRPs and nothing else.
MPIO used a hack to StorPort/ScsiPort to replace “GenDisk” with “MpioDisk”, and then go the same way as above. You cannot hack MS’s binary, so you need a bus filter.
Also, I have a strong feeling Storage Spaces is implemented using the above way.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Thanks Maxim … let me peep into storage space
>
The bus filter approach works well and is the basis from several deployed
commercial products.
Mark Roddy
On Wed, May 27, 2015 at 10:43 AM, Maxim S. Shatskih
wrote:
> If you write the bus filter driver (filters each storage controller
> and attaches its own devnodes to the child LUN PDOs in MN_QUERY_RELATIONS
> path, then manages their lifetimes), then you can filter QUERY_ID on disks.
>
> In the filter, remove “GenDisk” ID (and probably some more IDs) to
> disallow disk.sys on this devnode. Instead, create a hidden (also filter
> “query capabilities”) devnode with your own IDs, which will be serviced by
> your driver (same bus filter or a second binary), with your own naming and
> PnP devinterface GUIDs.
>
> Then the rest of your code senses these “special disk” devices (which
> can be targets of SCSI SRBs still) and use them as physical disks for your
> RAID.
>
> The power policy owner for disks is implemented in a PDO (StorPort),
> so you do not need this piece of code. Just respond to Dx IRPs and nothing
> else.
>
> MPIO used a hack to StorPort/ScsiPort to replace “GenDisk” with
> “MpioDisk”, and then go the same way as above. You cannot hack MS’s binary,
> so you need a bus filter.
>
> Also, I have a strong feeling Storage Spaces is implemented using the
> above way.
>
> –
> Maxim S. Shatskih
> Microsoft MVP on File System And Storage
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> wrote in message news:xxxxx@ntdev…
> > Thanks Maxim … let me peep into storage space
> >
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Thanks Maxim/Mark for the direction. I will not say tha I completely got it as my knowledge is very limited … but it gave me the path to follow and try. Will work towards it and update what I am able to achieve.
Thanks again.
bus filters or virtual miniports are a solid way to go and both strategies are found in commercial products. for the latter, sample source can be found–do a search for miniport raid source.