From owner-freebsd-hackers Sat Aug 15 23:15:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA05273 for freebsd-hackers-outgoing; Sat, 15 Aug 1998 23:15:49 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA05267; Sat, 15 Aug 1998 23:15:47 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id AAA02488; Sun, 16 Aug 1998 00:09:29 -0600 (MDT) Date: Sun, 16 Aug 1998 00:09:29 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199808160609.AAA02488@narnia.plutotech.com> To: sos@FreeBSD.ORG cc: hackers@FreeBSD.ORG Subject: Re: TESTERS WANTED for new ATAPI CD/CDR/CDRW driver. Newsgroups: pluto.freebsd.hackers In-Reply-To: <199808151902.VAA08482@sos.freebsd.dk> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199808151902.VAA08482@sos.freebsd.dk> you wrote: > >> For what it's worth, I don't see much value in treating ATA disks as >> though they were SCSI disks; the overhead in translation is probably >> too high. On the other hand, I'm less sure about things that use the >> ATAPI packet protocol. > > The ATA driver with lowlevel ATAPI support _must_ be implemented in > all cases, the difference is if the ATAPI device are registered under > CAM (scsi) or if there are nataive ATAPI drivers instead. I don't understand why everyone has this misconception. CAM != SCSI. CAM is primarily a transaction routing service. As such, most of CAM is oblivious to the format of the transactions it routes. You could route raw ATAPI or ATA commands or whatever you desire, by adding new function codes and CCB definitions. Whether ATAPI or ATA devices under CAM would talk in terms of SCSI is up to the implementor, it is not mandated by CAM. Essentially what moving ATAPI and/or ATA to CAM would buy you is a common registration/timeout/error handling framework that corrects many of the defects that are inherent in the current SCSI code (and perhaps replicated elsewhere??). If it makes sense for the ATAPI peripheral and controller drivers to talk in terms of SCSI commands, feel free to implement it that way. If not, don't, but whatever you do, don't argue that the reason the code isn't under the CAM framework is because it forces your hand towards a particular communication scheme. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message