Date: Sun, 25 Apr 2010 12:44:48 -0600 From: Scott Long <scottl@samsco.org> To: Alexander Best <alexbestms@wwu.de> Cc: Jaakko Heinonen <jh@FreeBSD.org>, freebsd-current@FreeBSD.org, Andriy Gapon <avg@icyb.net.ua> Subject: Re: Switchover to CAM ATA? Message-ID: <EFC65DFC-AED0-4CB3-AD0D-BB4859C0249A@samsco.org> In-Reply-To: <permail-20100425102325f0889e84000077fa-a_best01@message-id.uni-muenster.de> References: <permail-20100425102325f0889e84000077fa-a_best01@message-id.uni-muenster.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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). >=20 >> I have thought about it. The mail I posted in December didn't >> generate >> any interest. >=20 > 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. >=20 > 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@, but also got no response = [1]. >=20 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EFC65DFC-AED0-4CB3-AD0D-BB4859C0249A>