From owner-freebsd-scsi Sun Sep 17 10:39:35 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id EF30437B43F for ; Sun, 17 Sep 2000 10:39:32 -0700 (PDT) Received: (from gibbs@localhost) by caspian.plutotech.com (8.9.3/8.9.1) id RAA00812; Sat, 5 Aug 2000 17:48:40 -0600 (MDT) (envelope-from gibbs) Date: Sat, 5 Aug 2000 17:48:40 -0600 (MDT) Message-Id: <200008052348.RAA00812@caspian.plutotech.com> From: "Justin T. Gibbs" To: mjacob@feral.com Cc: scsi@FreeBSD.org Subject: Re: CAM layer X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > Well, the 'needs' was Justin's take on things. I'm not sure I agree. I tend to > see ATA like I implement SAF-TE inside SES- SCSI/CAM is a superset of what ATA > uses, although there are things in ANSI t13 committee that are not well > represented within t10 (SCSI) yet but can be shoehorned in pretty easily. Regardless of how the person integrating ATA/ATAPI into CAM decides to do this, I feel that the CAM layer should be separated out so that additional protocol types can be grafted to the base. This gives the implementer full flexibility to add support for a new stack in whichever manner seems best. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message