| Author |
Message |
Tom Stewart
Guest
|
 Posted:
Tue Jun 15, 2004 8:38 pm Post subject:
scsi inquiry cdb's |
|
|
Sorry, I'm sure this isn't the best group, but I only have access to the MS news servers at the moment. We're trying to
come up with a "proprietary" code page for a proprietary inquiry command. We have software that sits between an
application and raw physical drives. Normally, if the app issued an inquiry, we'd just do a SCSI pass-through to the
drive beneath us, but we want to be able to pass some "internal" information back to the application.
So, a couple of questions related to this. Is there a list of "standard" code pages (page codes?) somewhere so I could
know what to avoid? Is EVPD always ON if pagecode is non-zero? While it would be highly unusual for us to do anything
other than a vanilla inquiry, I'd like for us to not get in our own way should the need arise...
Thanks for any help. |
|
| Back to top |
|
 |
Jeff Goldner [MS]
Guest
|
| Posted:
Thu Jun 17, 2004 10:14 am Post subject:
Re: scsi inquiry cdb's |
|
|
I don't think I fully understand your request. Is this your own device? And
is your "app" a filter driver?
Vendor unique pages use C0-FF (See spc-3 - current revision is at
http://www.t10.org/ftp/t10/drafts/spc3/spc3r19.pdf, section 7.6.1. Yes, you
use EVPD=1. You should be careful using vendor unique code pages on devices
that are not your own.
"Tom Stewart" <tastewar@newsgroups.nospam> wrote in message
news:OF7nicvUEHA.704@TK2MSFTNGP09.phx.gbl...
| Quote: | Sorry, I'm sure this isn't the best group, but I only have access to the
MS news servers at the moment. We're trying to
come up with a "proprietary" code page for a proprietary inquiry command.
We have software that sits between an
application and raw physical drives. Normally, if the app issued an
inquiry, we'd just do a SCSI pass-through to the
drive beneath us, but we want to be able to pass some "internal"
information back to the application.
So, a couple of questions related to this. Is there a list of "standard"
code pages (page codes?) somewhere so I could
know what to avoid? Is EVPD always ON if pagecode is non-zero? While it
would be highly unusual for us to do anything
other than a vanilla inquiry, I'd like for us to not get in our own way
should the need arise...
Thanks for any help.
|
|
|
| Back to top |
|
|
Tom Stewart
Guest
|
| Posted:
Fri Jun 18, 2004 5:35 pm Post subject:
Re: scsi inquiry cdb's |
|
|
Hi Jeff- thanks for your interest. We have an app that is essentially a port of an operating system (MAGIC) that runs on
many hardware platforms. In order to maintain the vast majority of the source code to be the same across platforms, the
OS/application assembles its own SCSI CDB's, as it is accustomed to sending them directly to hardware via its own device
drivers. On the Windows platform, we have a layer of software (the Operating System Abstraction Layer -- OSAL) that sits
between MAGIC and Windows which translates these CDB's (and other i/o requests) into ReadFile and WriteFile requests.
And that accounts for 99.999% of the SCSI commands we issue. But, being conceptually an OS, it does want to inventory
devices, and query devices, etc. We originally (in our OSAL) tried to map the real hardware address to the address that
Magic sees, as this seemed to make things easier for support -- if I'm talking about CSL 2,1,0, we all know which device
that is.
In recent years, with the advent of SANs and fibre channel, and transparent failover drivers, etc., sometimes the CSL
changes mid-flight -- not something this legacy OS cares to know about. Not necessarily a problem, since we can still
let Magic use the old address (since we have a HANDLE to the disk) but when you talk about adding devices on the fly
it's conceivable that a new device will get an address that conflicts with one of the "old" addresses we used to know
about. So, we've re-vamped our mapping entirely, algorithmically generating a CSL based on the physical drive number,
based on a fundamental belief that that ain't gonna change while we have a handle to it.
All very good, except that for support purposes, we do on occasion want to know what the "real" (current) address is. We
can very easily have Magic craft a special inquiry CDB (using a non-zero pagecode) and when the OSAL intercepts it (it's
not a filter driver, it's just code that gets linked in to the .EXE, so it's actually a call) we can detect that it's
"the special flavor" inquiry and handle it ourselves, filling in Magic's buffer with our own info about the device
(including the current address), rather than taking the normal route which would be to send it down to the device via
scsi passthrough.
It's not hard, and all the code is in place to do this, I just want to make the best choice of inquiry parameters so
that we wouldn't be intercepting a real, valid inquiry. For instance, when running on an EVA storage platform, we issue
an inquiry with EVPD true and a pagecode of 131 which the storage system will answer by filling in the buffer with the
WWN of the device. I know that there are some well defined pagecodes, but I don't know of a nice reference which lists
them. For instance, there is one which returns a list of all the valid pagecodes that one might inquire against. Also,
if it were true that for all non-zero pagecodes, EVPD must be asserted, then I could very easily pick a combination
such as EVPD off and pagecode 210, or whatever, confident that if I did pass it down to the hardware it would just
generate an error.
Thanks if you've read this far, and even more if you can help :-)
--
Tom
"Jeff Goldner [MS]" <jeffgo@iworkatmicrosoft> wrote in message news:uHjwocPVEHA.1472@TK2MSFTNGP09.phx.gbl...
| Quote: | I don't think I fully understand your request. Is this your own device? And
is your "app" a filter driver?
Vendor unique pages use C0-FF (See spc-3 - current revision is at
http://www.t10.org/ftp/t10/drafts/spc3/spc3r19.pdf, section 7.6.1. Yes, you
use EVPD=1. You should be careful using vendor unique code pages on devices
that are not your own.
"Tom Stewart" <tastewar@newsgroups.nospam> wrote in message
news:OF7nicvUEHA.704@TK2MSFTNGP09.phx.gbl...
Sorry, I'm sure this isn't the best group, but I only have access to the
MS news servers at the moment. We're trying to
come up with a "proprietary" code page for a proprietary inquiry command.
We have software that sits between an
application and raw physical drives. Normally, if the app issued an
inquiry, we'd just do a SCSI pass-through to the
drive beneath us, but we want to be able to pass some "internal"
information back to the application.
So, a couple of questions related to this. Is there a list of "standard"
code pages (page codes?) somewhere so I could
know what to avoid? Is EVPD always ON if pagecode is non-zero? While it
would be highly unusual for us to do anything
other than a vanilla inquiry, I'd like for us to not get in our own way
should the need arise...
Thanks for any help.
|
|
|
| Back to top |
|
|
Jeff Goldner [MS]
Guest
|
| Posted:
Thu Jun 24, 2004 8:17 am Post subject:
Re: scsi inquiry cdb's |
|
|
Defined page codes are in SPC-3 (again,
http://www.t10.org/ftp/t10/drafts/spc3/spc3r19.pdf). This tells you that
page 131 (decimal) is really page 83h, which is the device identifier page.
Vendor unique page codes start at C0. I know of several vendors that use
these, including IBM. If you started at FF and worked your way down, you
might be safe.
"Tom Stewart" <tastewar@newsgroups.nospam> wrote in message
news:eneXvkTVEHA.1472@TK2MSFTNGP09.phx.gbl...
| Quote: | Hi Jeff- thanks for your interest. We have an app that is essentially a
port of an operating system (MAGIC) that runs on
many hardware platforms. In order to maintain the vast majority of the
source code to be the same across platforms, the
OS/application assembles its own SCSI CDB's, as it is accustomed to
sending them directly to hardware via its own device
drivers. On the Windows platform, we have a layer of software (the
Operating System Abstraction Layer -- OSAL) that sits
between MAGIC and Windows which translates these CDB's (and other i/o
requests) into ReadFile and WriteFile requests.
And that accounts for 99.999% of the SCSI commands we issue. But, being
conceptually an OS, it does want to inventory
devices, and query devices, etc. We originally (in our OSAL) tried to map
the real hardware address to the address that
Magic sees, as this seemed to make things easier for support -- if I'm
talking about CSL 2,1,0, we all know which device
that is.
In recent years, with the advent of SANs and fibre channel, and
transparent failover drivers, etc., sometimes the CSL
changes mid-flight -- not something this legacy OS cares to know about.
Not necessarily a problem, since we can still
let Magic use the old address (since we have a HANDLE to the disk) but
when you talk about adding devices on the fly
it's conceivable that a new device will get an address that conflicts with
one of the "old" addresses we used to know
about. So, we've re-vamped our mapping entirely, algorithmically
generating a CSL based on the physical drive number,
based on a fundamental belief that that ain't gonna change while we have a
handle to it.
All very good, except that for support purposes, we do on occasion want to
know what the "real" (current) address is. We
can very easily have Magic craft a special inquiry CDB (using a non-zero
pagecode) and when the OSAL intercepts it (it's
not a filter driver, it's just code that gets linked in to the .EXE, so
it's actually a call) we can detect that it's
"the special flavor" inquiry and handle it ourselves, filling in Magic's
buffer with our own info about the device
(including the current address), rather than taking the normal route which
would be to send it down to the device via
scsi passthrough.
It's not hard, and all the code is in place to do this, I just want to
make the best choice of inquiry parameters so
that we wouldn't be intercepting a real, valid inquiry. For instance, when
running on an EVA storage platform, we issue
an inquiry with EVPD true and a pagecode of 131 which the storage system
will answer by filling in the buffer with the
WWN of the device. I know that there are some well defined pagecodes, but
I don't know of a nice reference which lists
them. For instance, there is one which returns a list of all the valid
pagecodes that one might inquire against. Also,
if it were true that for all non-zero pagecodes, EVPD must be asserted,
then I could very easily pick a combination
such as EVPD off and pagecode 210, or whatever, confident that if I did
pass it down to the hardware it would just
generate an error.
Thanks if you've read this far, and even more if you can help :-)
--
Tom
"Jeff Goldner [MS]" <jeffgo@iworkatmicrosoft> wrote in message
news:uHjwocPVEHA.1472@TK2MSFTNGP09.phx.gbl...
I don't think I fully understand your request. Is this your own device?
And
is your "app" a filter driver?
Vendor unique pages use C0-FF (See spc-3 - current revision is at
http://www.t10.org/ftp/t10/drafts/spc3/spc3r19.pdf, section 7.6.1. Yes,
you
use EVPD=1. You should be careful using vendor unique code pages on
devices
that are not your own.
"Tom Stewart" <tastewar@newsgroups.nospam> wrote in message
news:OF7nicvUEHA.704@TK2MSFTNGP09.phx.gbl...
Sorry, I'm sure this isn't the best group, but I only have access to
the
MS news servers at the moment. We're trying to
come up with a "proprietary" code page for a proprietary inquiry
command.
We have software that sits between an
application and raw physical drives. Normally, if the app issued an
inquiry, we'd just do a SCSI pass-through to the
drive beneath us, but we want to be able to pass some "internal"
information back to the application.
So, a couple of questions related to this. Is there a list of
"standard"
code pages (page codes?) somewhere so I could
know what to avoid? Is EVPD always ON if pagecode is non-zero? While it
would be highly unusual for us to do anything
other than a vanilla inquiry, I'd like for us to not get in our own way
should the need arise...
Thanks for any help.
|
|
|
| Back to top |
|
|
Tom Stewart
Guest
|
| Posted:
Thu Jun 24, 2004 3:39 pm Post subject:
Re: scsi inquiry cdb's |
|
|
Thanks again Jeff. Would it be "safer" to use EVPD=0 with a non-zero, vendor-unique page
code then?
--
Tom
"Jeff Goldner [MS]" <jeffgo@iworkatmicrosoft> wrote in message
news:ubLGlIaWEHA.2576@TK2MSFTNGP10.phx.gbl...
| Quote: | Defined page codes are in SPC-3 (again,
http://www.t10.org/ftp/t10/drafts/spc3/spc3r19.pdf). This tells you that
page 131 (decimal) is really page 83h, which is the device identifier page.
Vendor unique page codes start at C0. I know of several vendors that use
these, including IBM. If you started at FF and worked your way down, you
might be safe.
"Tom Stewart" <tastewar@newsgroups.nospam> wrote in message
news:eneXvkTVEHA.1472@TK2MSFTNGP09.phx.gbl...
Hi Jeff- thanks for your interest. We have an app that is essentially a
port of an operating system (MAGIC) that runs on
many hardware platforms. In order to maintain the vast majority of the
source code to be the same across platforms, the
OS/application assembles its own SCSI CDB's, as it is accustomed to
sending them directly to hardware via its own device
drivers. On the Windows platform, we have a layer of software (the
Operating System Abstraction Layer -- OSAL) that sits
between MAGIC and Windows which translates these CDB's (and other i/o
requests) into ReadFile and WriteFile requests.
And that accounts for 99.999% of the SCSI commands we issue. But, being
conceptually an OS, it does want to inventory
devices, and query devices, etc. We originally (in our OSAL) tried to map
the real hardware address to the address that
Magic sees, as this seemed to make things easier for support -- if I'm
talking about CSL 2,1,0, we all know which device
that is.
In recent years, with the advent of SANs and fibre channel, and
transparent failover drivers, etc., sometimes the CSL
changes mid-flight -- not something this legacy OS cares to know about.
Not necessarily a problem, since we can still
let Magic use the old address (since we have a HANDLE to the disk) but
when you talk about adding devices on the fly
it's conceivable that a new device will get an address that conflicts with
one of the "old" addresses we used to know
about. So, we've re-vamped our mapping entirely, algorithmically
generating a CSL based on the physical drive number,
based on a fundamental belief that that ain't gonna change while we have a
handle to it.
All very good, except that for support purposes, we do on occasion want to
know what the "real" (current) address is. We
can very easily have Magic craft a special inquiry CDB (using a non-zero
pagecode) and when the OSAL intercepts it (it's
not a filter driver, it's just code that gets linked in to the .EXE, so
it's actually a call) we can detect that it's
"the special flavor" inquiry and handle it ourselves, filling in Magic's
buffer with our own info about the device
(including the current address), rather than taking the normal route which
would be to send it down to the device via
scsi passthrough.
It's not hard, and all the code is in place to do this, I just want to
make the best choice of inquiry parameters so
that we wouldn't be intercepting a real, valid inquiry. For instance, when
running on an EVA storage platform, we issue
an inquiry with EVPD true and a pagecode of 131 which the storage system
will answer by filling in the buffer with the
WWN of the device. I know that there are some well defined pagecodes, but
I don't know of a nice reference which lists
them. For instance, there is one which returns a list of all the valid
pagecodes that one might inquire against. Also,
if it were true that for all non-zero pagecodes, EVPD must be asserted,
then I could very easily pick a combination
such as EVPD off and pagecode 210, or whatever, confident that if I did
pass it down to the hardware it would just
generate an error.
Thanks if you've read this far, and even more if you can help :-)
--
Tom
"Jeff Goldner [MS]" <jeffgo@iworkatmicrosoft> wrote in message
news:uHjwocPVEHA.1472@TK2MSFTNGP09.phx.gbl...
I don't think I fully understand your request. Is this your own device?
And
is your "app" a filter driver?
Vendor unique pages use C0-FF (See spc-3 - current revision is at
http://www.t10.org/ftp/t10/drafts/spc3/spc3r19.pdf, section 7.6.1. Yes,
you
use EVPD=1. You should be careful using vendor unique code pages on
devices
that are not your own.
"Tom Stewart" <tastewar@newsgroups.nospam> wrote in message
news:OF7nicvUEHA.704@TK2MSFTNGP09.phx.gbl...
Sorry, I'm sure this isn't the best group, but I only have access to
the
MS news servers at the moment. We're trying to
come up with a "proprietary" code page for a proprietary inquiry
command.
We have software that sits between an
application and raw physical drives. Normally, if the app issued an
inquiry, we'd just do a SCSI pass-through to the
drive beneath us, but we want to be able to pass some "internal"
information back to the application.
So, a couple of questions related to this. Is there a list of
"standard"
code pages (page codes?) somewhere so I could
know what to avoid? Is EVPD always ON if pagecode is non-zero? While it
would be highly unusual for us to do anything
other than a vanilla inquiry, I'd like for us to not get in our own way
should the need arise...
Thanks for any help.
|
|
|
| Back to top |
|
|
Jeff Goldner [MS]
Guest
|
| Posted:
Fri Jun 25, 2004 8:00 am Post subject:
Re: scsi inquiry cdb's |
|
|
well, technically I think this violates the standard, but since you are
sending command to yourself you might not care. But what happens if this
gets to another vendors storage device?
"Tom Stewart" <tastewar@newsgroups.nospam> wrote in message
news:u5xX1$dWEHA.2176@TK2MSFTNGP11.phx.gbl...
| Quote: | Thanks again Jeff. Would it be "safer" to use EVPD=0 with a non-zero,
vendor-unique page
code then?
--
Tom
"Jeff Goldner [MS]" <jeffgo@iworkatmicrosoft> wrote in message
news:ubLGlIaWEHA.2576@TK2MSFTNGP10.phx.gbl...
Defined page codes are in SPC-3 (again,
http://www.t10.org/ftp/t10/drafts/spc3/spc3r19.pdf). This tells you that
page 131 (decimal) is really page 83h, which is the device identifier
page.
Vendor unique page codes start at C0. I know of several vendors that use
these, including IBM. If you started at FF and worked your way down, you
might be safe.
"Tom Stewart" <tastewar@newsgroups.nospam> wrote in message
news:eneXvkTVEHA.1472@TK2MSFTNGP09.phx.gbl...
Hi Jeff- thanks for your interest. We have an app that is essentially a
port of an operating system (MAGIC) that runs on
many hardware platforms. In order to maintain the vast majority of the
source code to be the same across platforms, the
OS/application assembles its own SCSI CDB's, as it is accustomed to
sending them directly to hardware via its own device
drivers. On the Windows platform, we have a layer of software (the
Operating System Abstraction Layer -- OSAL) that sits
between MAGIC and Windows which translates these CDB's (and other i/o
requests) into ReadFile and WriteFile requests.
And that accounts for 99.999% of the SCSI commands we issue. But, being
conceptually an OS, it does want to inventory
devices, and query devices, etc. We originally (in our OSAL) tried to
map
the real hardware address to the address that
Magic sees, as this seemed to make things easier for support -- if I'm
talking about CSL 2,1,0, we all know which device
that is.
In recent years, with the advent of SANs and fibre channel, and
transparent failover drivers, etc., sometimes the CSL
changes mid-flight -- not something this legacy OS cares to know about.
Not necessarily a problem, since we can still
let Magic use the old address (since we have a HANDLE to the disk) but
when you talk about adding devices on the fly
it's conceivable that a new device will get an address that conflicts
with
one of the "old" addresses we used to know
about. So, we've re-vamped our mapping entirely, algorithmically
generating a CSL based on the physical drive number,
based on a fundamental belief that that ain't gonna change while we
have a
handle to it.
All very good, except that for support purposes, we do on occasion want
to
know what the "real" (current) address is. We
can very easily have Magic craft a special inquiry CDB (using a
non-zero
pagecode) and when the OSAL intercepts it (it's
not a filter driver, it's just code that gets linked in to the .EXE, so
it's actually a call) we can detect that it's
"the special flavor" inquiry and handle it ourselves, filling in
Magic's
buffer with our own info about the device
(including the current address), rather than taking the normal route
which
would be to send it down to the device via
scsi passthrough.
It's not hard, and all the code is in place to do this, I just want to
make the best choice of inquiry parameters so
that we wouldn't be intercepting a real, valid inquiry. For instance,
when
running on an EVA storage platform, we issue
an inquiry with EVPD true and a pagecode of 131 which the storage
system
will answer by filling in the buffer with the
WWN of the device. I know that there are some well defined pagecodes,
but
I don't know of a nice reference which lists
them. For instance, there is one which returns a list of all the valid
pagecodes that one might inquire against. Also,
if it were true that for all non-zero pagecodes, EVPD must be
asserted,
then I could very easily pick a combination
such as EVPD off and pagecode 210, or whatever, confident that if I did
pass it down to the hardware it would just
generate an error.
Thanks if you've read this far, and even more if you can help :-)
--
Tom
"Jeff Goldner [MS]" <jeffgo@iworkatmicrosoft> wrote in message
news:uHjwocPVEHA.1472@TK2MSFTNGP09.phx.gbl...
I don't think I fully understand your request. Is this your own
device?
And
is your "app" a filter driver?
Vendor unique pages use C0-FF (See spc-3 - current revision is at
http://www.t10.org/ftp/t10/drafts/spc3/spc3r19.pdf, section 7.6.1.
Yes,
you
use EVPD=1. You should be careful using vendor unique code pages on
devices
that are not your own.
"Tom Stewart" <tastewar@newsgroups.nospam> wrote in message
news:OF7nicvUEHA.704@TK2MSFTNGP09.phx.gbl...
Sorry, I'm sure this isn't the best group, but I only have access to
the
MS news servers at the moment. We're trying to
come up with a "proprietary" code page for a proprietary inquiry
command.
We have software that sits between an
application and raw physical drives. Normally, if the app issued an
inquiry, we'd just do a SCSI pass-through to the
drive beneath us, but we want to be able to pass some "internal"
information back to the application.
So, a couple of questions related to this. Is there a list of
"standard"
code pages (page codes?) somewhere so I could
know what to avoid? Is EVPD always ON if pagecode is non-zero? While
it
would be highly unusual for us to do anything
other than a vanilla inquiry, I'd like for us to not get in our own
way
should the need arise...
Thanks for any help.
|
|
|
| Back to top |
|
|
Tom Stewart
Guest
|
| Posted:
Fri Jun 25, 2004 6:31 pm Post subject:
Re: scsi inquiry cdb's |
|
|
It should just return an error, according to the spec. But lacking a bug in our code, it
shouldn't get there.
Thanks again, Jeff.
--
Tom
"Jeff Goldner [MS]" <jeffgo@iworkatmicrosoft> wrote in message
news:eP6czjmWEHA.808@tk2msftngp13.phx.gbl...
| Quote: | well, technically I think this violates the standard, but since you are
sending command to yourself you might not care. But what happens if this
gets to another vendors storage device?
"Tom Stewart" <tastewar@newsgroups.nospam> wrote in message
news:u5xX1$dWEHA.2176@TK2MSFTNGP11.phx.gbl...
Thanks again Jeff. Would it be "safer" to use EVPD=0 with a non-zero,
vendor-unique page
code then?
--
Tom
"Jeff Goldner [MS]" <jeffgo@iworkatmicrosoft> wrote in message
news:ubLGlIaWEHA.2576@TK2MSFTNGP10.phx.gbl...
Defined page codes are in SPC-3 (again,
http://www.t10.org/ftp/t10/drafts/spc3/spc3r19.pdf). This tells you that
page 131 (decimal) is really page 83h, which is the device identifier
page.
Vendor unique page codes start at C0. I know of several vendors that use
these, including IBM. If you started at FF and worked your way down, you
might be safe.
"Tom Stewart" <tastewar@newsgroups.nospam> wrote in message
news:eneXvkTVEHA.1472@TK2MSFTNGP09.phx.gbl...
Hi Jeff- thanks for your interest. We have an app that is essentially a
port of an operating system (MAGIC) that runs on
many hardware platforms. In order to maintain the vast majority of the
source code to be the same across platforms, the
OS/application assembles its own SCSI CDB's, as it is accustomed to
sending them directly to hardware via its own device
drivers. On the Windows platform, we have a layer of software (the
Operating System Abstraction Layer -- OSAL) that sits
between MAGIC and Windows which translates these CDB's (and other i/o
requests) into ReadFile and WriteFile requests.
And that accounts for 99.999% of the SCSI commands we issue. But, being
conceptually an OS, it does want to inventory
devices, and query devices, etc. We originally (in our OSAL) tried to
map
the real hardware address to the address that
Magic sees, as this seemed to make things easier for support -- if I'm
talking about CSL 2,1,0, we all know which device
that is.
In recent years, with the advent of SANs and fibre channel, and
transparent failover drivers, etc., sometimes the CSL
changes mid-flight -- not something this legacy OS cares to know about.
Not necessarily a problem, since we can still
let Magic use the old address (since we have a HANDLE to the disk) but
when you talk about adding devices on the fly
it's conceivable that a new device will get an address that conflicts
with
one of the "old" addresses we used to know
about. So, we've re-vamped our mapping entirely, algorithmically
generating a CSL based on the physical drive number,
based on a fundamental belief that that ain't gonna change while we
have a
handle to it.
All very good, except that for support purposes, we do on occasion want
to
know what the "real" (current) address is. We
can very easily have Magic craft a special inquiry CDB (using a
non-zero
pagecode) and when the OSAL intercepts it (it's
not a filter driver, it's just code that gets linked in to the .EXE, so
it's actually a call) we can detect that it's
"the special flavor" inquiry and handle it ourselves, filling in
Magic's
buffer with our own info about the device
(including the current address), rather than taking the normal route
which
would be to send it down to the device via
scsi passthrough.
It's not hard, and all the code is in place to do this, I just want to
make the best choice of inquiry parameters so
that we wouldn't be intercepting a real, valid inquiry. For instance,
when
running on an EVA storage platform, we issue
an inquiry with EVPD true and a pagecode of 131 which the storage
system
will answer by filling in the buffer with the
WWN of the device. I know that there are some well defined pagecodes,
but
I don't know of a nice reference which lists
them. For instance, there is one which returns a list of all the valid
pagecodes that one might inquire against. Also,
if it were true that for all non-zero pagecodes, EVPD must be
asserted,
then I could very easily pick a combination
such as EVPD off and pagecode 210, or whatever, confident that if I did
pass it down to the hardware it would just
generate an error.
Thanks if you've read this far, and even more if you can help :-)
--
Tom
"Jeff Goldner [MS]" <jeffgo@iworkatmicrosoft> wrote in message
news:uHjwocPVEHA.1472@TK2MSFTNGP09.phx.gbl...
I don't think I fully understand your request. Is this your own
device?
And
is your "app" a filter driver?
Vendor unique pages use C0-FF (See spc-3 - current revision is at
http://www.t10.org/ftp/t10/drafts/spc3/spc3r19.pdf, section 7.6.1.
Yes,
you
use EVPD=1. You should be careful using vendor unique code pages on
devices
that are not your own.
"Tom Stewart" <tastewar@newsgroups.nospam> wrote in message
news:OF7nicvUEHA.704@TK2MSFTNGP09.phx.gbl...
Sorry, I'm sure this isn't the best group, but I only have access to
the
MS news servers at the moment. We're trying to
come up with a "proprietary" code page for a proprietary inquiry
command.
We have software that sits between an
application and raw physical drives. Normally, if the app issued an
inquiry, we'd just do a SCSI pass-through to the
drive beneath us, but we want to be able to pass some "internal"
information back to the application.
So, a couple of questions related to this. Is there a list of
"standard"
code pages (page codes?) somewhere so I could
know what to avoid? Is EVPD always ON if pagecode is non-zero? While
it
would be highly unusual for us to do anything
other than a vanilla inquiry, I'd like for us to not get in our own
way
should the need arise...
Thanks for any help.
|
|
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in