Jump to content











Photo
- - - - -

Raw Mode

imdisk winvblock

Best Answer Olof Lagerkvist , 07 December 2012 - 12:48 AM

You mean just specifying a device type other than FILE_DEVICE_DISK when calling IoCreateDevice, to keep filesystem drivers from mounting it?

http://msdn.microsof...e/ff563821.aspx

That would be just a matter of having a create device option for that. I can fix that for the next release or so.

 

It sounds like an interesting project that you are planning. I recently wrote a storage miniport driver as part of a larger commercial project. That one needed to support the same proxy communication as ImDisk uses, so I basically started from Microsoft's Virtual Storport Miniport sample and copied in the proxy client functions from ImDisk. Your approach is somewhat different in that it will use the actual ImDisk driver with all backend features it provides, without the risks of "copy-paste errors" and without the need to transfer all per-device metadata logic from ImDisk source to your source. That sounds like a good idea. It will keep each component doing what it does best and has been long-time tested for.

 

:cheers:

Go to the full post


  • Please log in to reply
3 replies to this topic

#1 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 06 December 2012 - 10:47 PM

Hey Olof,

Would you possibly be interested in developing a "raw mode" for ImDisk disks, where the device wouldn't expose a disk interface nor mounting volumes? If you can leave such devices "hanging around," then I can have WinVBlock find them and do PnP and SCSI translation for them.

What do you think?

#2 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1334 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 07 December 2012 - 12:48 AM   Best Answer

You mean just specifying a device type other than FILE_DEVICE_DISK when calling IoCreateDevice, to keep filesystem drivers from mounting it?

http://msdn.microsof...e/ff563821.aspx

That would be just a matter of having a create device option for that. I can fix that for the next release or so.

 

It sounds like an interesting project that you are planning. I recently wrote a storage miniport driver as part of a larger commercial project. That one needed to support the same proxy communication as ImDisk uses, so I basically started from Microsoft's Virtual Storport Miniport sample and copied in the proxy client functions from ImDisk. Your approach is somewhat different in that it will use the actual ImDisk driver with all backend features it provides, without the risks of "copy-paste errors" and without the need to transfer all per-device metadata logic from ImDisk source to your source. That sounds like a good idea. It will keep each component doing what it does best and has been long-time tested for.

 

:cheers:



#3 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 07 December 2012 - 02:15 AM

You mean just specifying a device type other than FILE_DEVICE_DISK when calling IoCreateDevice, to keep filesystem drivers from mounting it?
http://msdn.microsof...e/ff563821.aspx
That would be just a matter of having a create device option for that. I can fix that for the next release or so.

That'd be great, if you could. It might be nice if you used a custom FILE_DEVICE_XXX device type that I could search for instances of (or rather, receive notifications for arrivals of).

It sounds like an interesting project that you are planning. I recently wrote a storage miniport driver as part of a larger commercial project. That one needed to support the same proxy communication as ImDisk uses, so I basically started from Microsoft's Virtual Storport Miniport sample and copied in the proxy client functions from ImDisk. Your approach is somewhat different in that it will use the actual ImDisk driver with all backend features it provides, without the risks of "copy-paste errors" and without the need to transfer all per-device metadata logic from ImDisk source to your source.

And without needing to track two source code repositories too closely. :)

That sounds like a good idea. It will keep each component doing what it does best and has been long-time tested for.

I'm glad you think so! Thanks for your interest!

#4 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1334 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 10 March 2013 - 07:22 PM

Just wanted to re-activate this thread and remind about the 1.7.0 beta release, where the feature requested in this thread has been introduced.

 

:cheers:







Also tagged with one or more of these keywords: imdisk, winvblock

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users