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" 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.
>
>

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]" 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" 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.
> >
> >
>
>

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" 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]" 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" 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.
>> >
>> >
>>
>>
>
>

Thanks again Jeff. Would it be "safer" to use EVPD=0 with a non-zero, vendor-unique page
code then?

--
Tom

"Jeff Goldner [MS]" 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" 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]" 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" 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.
> >> >
> >> >
> >>
> >>
> >
> >
>
>

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" 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]" 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" 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]" 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" 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.
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

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]" wrote in message
news:eP6czjmWEHA.808@tk2msftngp13.phx.gbl...
> 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" 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]" 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" 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]" 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" 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.
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>