In article Pine.BSF.4.21.0103211840550.79471-10@localhost,
Max Khon [EMAIL PROTECTED] wrote:
hi, there!
On Tue, 20 Mar 2001, Mike Smith wrote:
Has anyone implemented/thought of implementing:
- a CAM transport for ATAPI devices;
Yes. It's not a lot of work.
that would
It seems Thomas Quinot wrote:
Le 2001-03-21, Mike Smith crivait :
Has anyone implemented/thought of implementing:
- a CAM transport for ATAPI devices;
Yes. It's not a lot of work.
Ah, interesting! Do you know if any source code is publicly available?
What do you want it for
Le 2001-03-21, Soren Schmidt crivait :
- a CAM transport for ATAPI devices;
What do you want it for actually ?
It is a possible solution for me to be able to use cdparanoia and cdrdao
with my ATAPI CD drive. An alternative solution would be to implement
an atapi-cd ioctl to send a raw
Le 2001-03-21, Mike Smith crivait :
SCSI is way of encapsulating scanner commands so that you can transport
them to the scanner. So is USB. The command set your scanner uses is
probably the same as the SCSI command set, but this is not what a CAM
transport would give you - it would only
It seems Thomas Quinot wrote:
Le 2001-03-21, Soren Schmidt crivait :
- a CAM transport for ATAPI devices;
What do you want it for actually ?
It is a possible solution for me to be able to use cdparanoia and cdrdao
with my ATAPI CD drive. An alternative solution would be to
On 21-Mar-01 Thomas Quinot wrote:
Um. The CAM tranport in question would not be a reimplementation of
the USB layer, of course. What I was mentioning was the possibility
of having a CAM transport that wraps a uscan device (just as there is
one already that wraps umass devices to make
hi, there!
On Tue, 20 Mar 2001, Mike Smith wrote:
Has anyone implemented/thought of implementing:
- a CAM transport for ATAPI devices;
Yes. It's not a lot of work.
that would be GREAT for cd recording on IDE CD-RW (one will be able to
use cdrdao and cdrecord instead of burncd)
/fjoe
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
- the Linux SCSI generic device (/dev/sg*)?
We already have a far superior mechanism (/dev/pass*)
FWIW,
The Linux /dev/sg was implemented as a simple way to send SCSI commands to
media changer robots in an MO drive library for a
Thomas Quinot [EMAIL PROTECTED] writes:
Has anyone implemented/thought of implementing:
- a CAM transport for ATAPI devices;
- a CAM transport for USB scanners;
- the Linux SCSI generic device (/dev/sg*)?
FreeBSD already has an equivalent to the SCSI generic device -- take a
look at
Le 2001-03-19, Nat Lanza crivait :
FreeBSD already has an equivalent to the SCSI generic device -- take a
look at pass(4).
Yep, I am aware of pass(4), but some closed-source software that
comes only as Linux binaries insist on having a /dev/sg device
(which, under FreeBSD, would most likely
10 matches
Mail list logo
