Let’s say I would want to write a CD Cloner like program, I would need
to send “raw” command to the scsi device, under Windows the ASPI
layer provide some features for that.
Is there any equivalment on NTO. Would I be stuck sending
raw SCSI command? How would I go about doing this? What
if the device is on IDE?
\
“Igor Kovalenko” <Igor.Kovalenko@motorola.com> wrote in message
news:8upkuf$jru$1@inn.qnx.com…
Mario Charest <> mcharest@zzinformatic.com> > wrote in message
news:8uompn$jo8$> 1@inn.qnx.com> …
Let’s say I would want to write a CD Cloner like program, I would need
to send “raw” command to the scsi device, under Windows the ASPI
layer provide some features for that.Is there any equivalment on NTO. Would I be stuck sending
raw SCSI command? How would I go about doing this? What
if the device is on IDE?
I had thoughts about that too Mario >
Hehe! Actualy I use CD Cloner as an analogy 
It’s not reall CD Cloning,
but the task requires complete controle of what is happening ( CD Cloning
is just a subset of it all…)
The Unix equivalent of ASPI is CAM (Common Access Methods). If it is
supported by OS, it will have /dev/cam or such, which would allow you to
at
least target raw SCSI commands properly. RTP currently has libcam.so but
support of CAM is very rudimentary, there is no /dev/cam and no API. They
promiced to bring it on and I decided to hold until that’s done. Until
then
it’s just too awkward to do anything, since you don’t even have device
names
for some particular devices (tapes, scanners, the controller itself, etc).
Where would you send commands then… >EIDE devices should be covered by CAM as well. See FreeBSD for an example
of
CAM implementation.
Thanks Igor.
I have ask the same question in QNX4 conference (the customer needs to
decide which of QNX4 or NTO suites the job best).
- igor
Mario Charest <mcharest@zzinformatic.com> wrote in message
news:8uompn$jo8$1@inn.qnx.com…
Let’s say I would want to write a CD Cloner like program, I would need
to send “raw” command to the scsi device, under Windows the ASPI
layer provide some features for that.Is there any equivalment on NTO. Would I be stuck sending
raw SCSI command? How would I go about doing this? What
if the device is on IDE?
I had thoughts about that too Mario
The Unix equivalent of ASPI is CAM (Common Access Methods). If it is
supported by OS, it will have /dev/cam or such, which would allow you to at
least target raw SCSI commands properly. RTP currently has libcam.so but
support of CAM is very rudimentary, there is no /dev/cam and no API. They
promiced to bring it on and I decided to hold until that’s done. Until then
it’s just too awkward to do anything, since you don’t even have device names
for some particular devices (tapes, scanners, the controller itself, etc).
Where would you send commands then…
EIDE devices should be covered by CAM as well. See FreeBSD for an example of
CAM implementation.
Igor Kovalenko wrote:
Is there any equivalment on NTO. Would I be stuck sending
raw SCSI command? How would I go about doing this? What
if the device is on IDE?
I had thoughts about that too Mario >
The Unix equivalent of ASPI is CAM (Common Access Methods). If it is
supported by OS, it will have /dev/cam or such, which would allow you to at
least target raw SCSI commands properly. RTP currently has libcam.so but
support of CAM is very rudimentary, there is no /dev/cam and no API.
Whilst a “/dev/cam” entry would be nice for targetting commands to a
specific path/target/lun on a complicated system, on most setups you
can use the devctl re-direction feature of the VFS layer to target the
disk driver using entries that already exist in the pathname space.
You can issue a DCMD_CAM_PASS_THRU devctl() to “/dev/hd0” or
“/dev/cd0” or in fact any regular file on top of the desired device,
and it will filter down to the disk driver layer for processing.
The trick is in knowing how to build the request/SCSI CDB and in being
very, very, VERY careful, since you can cause a lot of fatal problems
(and interfere with normal driver/filesystem operation) if you don’t
know
exactly what you’re doing when accessing the device at this low-level
(and accordingly you won’t receive any official/Kevin support 
… !!
EIDE devices should be covered by CAM as well.
Yes, you can target these raw commands at devb-eide devices too
(where SCSI/EIDE/ATAPI command-sets overlap).
Heh. License to pillage and plunder: granted
“John Garvey” <jpg@cisco.com> wrote in message
news:3A1ABA2B.5349C456@cisco.com…
Whilst a “/dev/cam” entry would be nice for targetting commands to a
specific path/target/lun on a complicated system, on most setups you
can use the devctl re-direction feature of the VFS layer to target the
disk driver using entries that already exist in the pathname space.You can issue a DCMD_CAM_PASS_THRU devctl() to “/dev/hd0” or
“/dev/cd0” or in fact any regular file on top of the desired device,
and it will filter down to the disk driver layer for processing.The trick is in knowing how to build the request/SCSI CDB and in being
very, very, VERY careful, since you can cause a lot of fatal problems
(and interfere with normal driver/filesystem operation) if you don’t
know
exactly what you’re doing when accessing the device at this low-level
(and accordingly you won’t receive any official/Kevin support >
(We’ll just overlook that part. We know where Kevin lives…
EIDE devices should be covered by CAM as well.
Yes, you can target these raw commands at devb-eide devices too
(where SCSI/EIDE/ATAPI command-sets overlap).
John Garvey <jpg@cisco.com> wrote:
Igor Kovalenko wrote:
Is there any equivalment on NTO. Would I be stuck sending
raw SCSI command? How would I go about doing this? What
if the device is on IDE?
I had thoughts about that too Mario >
The Unix equivalent of ASPI is CAM (Common Access Methods). If it is
supported by OS, it will have /dev/cam or such, which would allow you to at
least target raw SCSI commands properly. RTP currently has libcam.so but
support of CAM is very rudimentary, there is no /dev/cam and no API.Whilst a “/dev/cam” entry would be nice for targetting commands to a
specific path/target/lun on a complicated system, on most setups you
can use the devctl re-direction feature of the VFS layer to target the
disk driver using entries that already exist in the pathname space.You can issue a DCMD_CAM_PASS_THRU devctl() to “/dev/hd0” or
“/dev/cd0” or in fact any regular file on top of the desired device,
and it will filter down to the disk driver layer for processing.
This interface will be changing and will not be supported in the future.
Kevin Chiles wrote:
John Garvey wrote:
You can issue a DCMD_CAM_PASS_THRU devctl() to “/dev/hd0” or
“/dev/cd0” or in fact any regular file on top of the desired device,
and it will filter down to the disk driver layer for processing.This interface will be changing and will not be supported in the future.
As opposed to not being supported in the past or present … ?!