If you write the virtual disk driver as a SCSI miniport, you need not
worry about such things. Let the real disk class driver handle that
stuff.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Cariddi
Sent: Tuesday, July 03, 2001 7:58 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Virtual disk with a bus enumerator
(SRB_FUNCTION_ - - CLAIM_DEVICE) ?
I would say that your just lucky. NT “likes” to remember
disks across
reboots. You should always use the same id if the disk is
the same. If
the disk size changes, then you have to decide; is this the
same disk, just bigger (note: basic disks can be extended in
windows 2000) or is this a new
disk with a different format? I use UUID’s to uniquely
identify the disks,
I can’t remember what I use to uniquely identify virtual
Cdroms (iso files).
–Mark
-----Original Message-----
From: xxxxx@hotmail.com
[mailto:xxxxx@hotmail.com]
Sent: Monday, July
02, 2001 9:00 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Virtual disk with a bus enumerator
(SRB_FUNCTION_- -
CLAIM_DEVICE) ?
> BTW, the signature comes back as part of the
IOCTL_STORAGE_QUERY_PROPERTY
> StorageDeviceProperty call. Be sure that each of your
disks has a unique
> ID, i.e signature…
I just generate for device ID the string with the index of
the device.
Like
“StarDisk %d on StarPort Controller”. So the disk numbers are
unique. But
they are not across boots. And the disks with the same names can have
different sizes if they are created/destroyed. I mean I can create
“StarDisk 0” with 10 megabytes in size, use it, destroy and create
“StarDisk 0” with 100 megabytes in size. It works for me
now… Is this OK
or I’m just lucky?
You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as:
xxxxx@storagecraft.com To unsubscribe send a blank email to
leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
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
I can use neither ScsiPort not StorPort b/s I need to complete requests in
my own driver context not in ScsiPort or StorPort one. That’s why there is
no way to use miniport model for me. I can implement the disk as SCSI class
driver (and actually did it for Windows NT 4.0) but I do not want to add
new IOCTLs every time new version of Windows comes. Gave up idea of having
disk written as SCSI class driver or SCSI miniport and writing it as SCSI
port driver. That’s all.
If you write the virtual disk driver as a SCSI miniport, you need not
worry about such things. Let the real disk class driver handle that
stuff.
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
If you write your own SCSI port driver with your own miniport model,
then it is possible. SCSI port limitation of requiring SCSI port context
to complete a request is only a limitation imposed my Microsoft. Our
SCSI port driver/miniport model can complete requests in ANY context.
Including a completion routine of another driver.
Using SCSI is guaranteed not to change. SCSI is SCSI. If you need
additional functionality, consider extending the SCSI command set to use
vendor specific CDB, mode pages or log pages.
Writing a disk class driver will surly ensure major changes between
versions of Windows.
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, July 04, 2001 11:52 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Virtual disk with a bus enumerator
(SRB_FUNCTION_ - - CLAIM_DEVICE) ?
I can use neither ScsiPort not StorPort b/s I need to
complete requests in
my own driver context not in ScsiPort or StorPort one. That’s
why there is
no way to use miniport model for me. I can implement the disk
as SCSI class
driver (and actually did it for Windows NT 4.0) but I do not
want to add
new IOCTLs every time new version of Windows comes. Gave up
idea of having
disk written as SCSI class driver or SCSI miniport and
writing it as SCSI
port driver. That’s all.
> If you write the virtual disk driver as a SCSI miniport,
you need not
> worry about such things. Let the real disk class driver handle that
> stuff.
You are currently subscribed to ntdev as:
xxxxx@storagecraft.com To unsubscribe send a blank email to
leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
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
Own SCSI port driver (full driver/minidriver model) is exactly what I’m
writing. I do not think there will be any use for me from your SCSI port
driver as I need to support my existing minidriver model which is different
from the one Microsoft provides and you support.
I do not need additional functionality. Only disk devices right now. Just
to map their virtual media on other machines file using TDI.
On 07/04/01, ““Jamey Kirby” ” wrote:
> If you write your own SCSI port driver with your own miniport model,
> then it is possible. SCSI port limitation of requiring SCSI port context
> to complete a request is only a limitation imposed my Microsoft. Our
> SCSI port driver/miniport model can complete requests in ANY context.
> Including a completion routine of another driver.
>
> Using SCSI is guaranteed not to change. SCSI is SCSI. If you need
> additional functionality, consider extending the SCSI command set to use
> vendor specific CDB, mode pages or log pages.
>
> Writing a disk class driver will surly ensure major changes between
> versions of Windows.
>
> Jamey
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of
> > xxxxx@hotmail.com
> > Sent: Wednesday, July 04, 2001 11:52 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: Virtual disk with a bus enumerator
> > (SRB_FUNCTION_ - - CLAIM_DEVICE) ?
> >
> >
> > I can use neither ScsiPort not StorPort b/s I need to
> > complete requests in
> > my own driver context not in ScsiPort or StorPort one. That’s
> > why there is
> > no way to use miniport model for me. I can implement the disk
> > as SCSI class
> > driver (and actually did it for Windows NT 4.0) but I do not
> > want to add
> > new IOCTLs every time new version of Windows comes. Gave up
> > idea of having
> > disk written as SCSI class driver or SCSI miniport and
> > writing it as SCSI
> > port driver. That’s all.
> >
> > > If you write the virtual disk driver as a SCSI miniport,
> > you need not
> > > worry about such things. Let the real disk class driver handle that
> > > stuff.
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@storagecraft.com To unsubscribe send a blank email to
> > leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
>
> —
> 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
—
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