Re: Switchover to CAM ATA?

From: Scott Long <scottl_at_samsco.org>
Date: Sun, 25 Apr 2010 12:44:48 -0600
On Apr 25, 2010, at 4:23 AM, Alexander Best wrote:
> Jaakko Heinonen schrieb am 2010-04-23:
>> On 2010-04-23, Alexander Best wrote:
>>> has anybody thought about adding scsi support to burncd(8)? i've
>>> been using
>>> ATA CAM for quite a while now and really love it. however i miss
>>> burncd(8).
> 
>> I have thought about it. The mail I posted in December didn't
>> generate
>> any interest.
> 
> i'm sorry i didn't notice your mail back then. i'm very interested in using
> burncd on a pass(4) device and would like to test any patches you may have.
> 
> another option would be to have a ata(4)->cam(4)->ata(4) emulation. layer (the
> opposite of the current ATA_CAM option). that way all ata binaries would
> continue to work.  what /dev/ata* would be used for is to receive ata
> commands, convert them to cam commands and then send them to pass. i wrote a
> mail with the idea to freebsd-questions_at_, but also got no response [1].
> 

Compatibility is a good thing, and I see nothing wrong with adding a simple ioctl module
to the pass or cd driver that achieves this.  The only thing that I'd worry about is that
there might be semantics to the old ata ioctls that rely on quirky operations of the old
ata driver.  It's really going to be counter-productive to try too hard to emulate the old
driver; the whole point of CAM_ATA is to move on from the sins of it.  Also, other than
burncd, what else exists to justify this emulation layer?  If it's just burncd, have you
considered writing a CAM-oriented replacement for it?  Maybe something that is as
versatile as cdrecord, but with an unencumbered BSD license so it can exist in the base
system?

Scott
Received on Sun Apr 25 2010 - 16:44:47 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC