From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 17:33:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DAC4106564A for ; Fri, 5 Jun 2009 17:33:01 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id BB3888FC0C for ; Fri, 5 Jun 2009 17:33:00 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n55HWsYH006880; Fri, 5 Jun 2009 11:32:54 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A2956C6.5070902@samsco.org> Date: Fri, 05 Jun 2009 11:32:54 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Matthew Dillon References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> In-Reply-To: <200906050703.n5573x5Q071765@apollo.backplane.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Alexander Motin , FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 17:33:01 -0000 Matthew Dillon wrote: > :Hi. > : > :After replying to several similar questions about my ATA plans last > :time, I have decided to announce things I am working on now together > :with Scott Long. > : > :While learning FreeBSD ATA implementation, I have found, that it has > :numerous deep problems, from quite fuzzy APIs to different issues in > :device detection and error recovery. Also, as soon as this > :infrastructure was written many years ago, it has completely no support > :for any kind of command queuing, which is normal for the most of modern > :drives and controllers. Fixing all of this require many significant changes. > : > :Also, you may know, that SAS controllers and expanders allow attaching > :SATA devices and port multipliers to them, by transporting ATA commands > :... > :project of making CAM a system's universal infrastructure for both SCSI > :and ATA. This project is not about some kind of SCSI-to-ATA translation, > :used by some OS, like OpenBSD. It is about extending CAM, to equally > :support both SCSI and ATA worlds natively and integrate them as tight as > :possible. > : > :... > :Our code now lives in PERFORCE in scottl-camlock project branch. It is > :in early development, but we already have there working CAM driver for > :AHCI controller with command queuing and basic NCQ support, simple SATA > :bus management code and ATA disk driver. I am able now to boot my system > :and work from SATA drive on AHCI controller, using ATA disk driver, > :having command queuing and NCQ enabled, read and write disks with SATA > :ATAPI DVD-RW drive, using native SCSI CD driver. And all of that only > :with CAM, without using any part of ATA infrastructure. > : > :-- > :Alexander Motin > > The biggest issue with AHCI (and ATA) interfacing is that AHCI devices > attach either as DISK or ATAPI. A device which attaches as a DISK > does not typically support ATAPI commands (though it would be an > interesting experiment to see if some did). This means that no matter > what you do a SCSI<->ATA translation layer needs to do some significant > fake-ups for DISK attachments, similar to what OpenBSD does in their > SCSI<->ATA layer. ATA DISK attachments simply do not support enough > of the SCSI command set for direct integration into CAM (IMHO). CAM is being expanded to be a framework for scheduling, recovery, and topology management, agnostic to the transport and protocol being used. SPI and SCSI are being separated into transport and protocol modules, and Alexander has been amazing and kind enough to start a SATA transport and ATA protocol module. Unlike Linux, OpenBSD, or anything else out there, this is not a tacked-on library for speaking SCSI/SPI at the top level and then translating it to something else at a lower level. This is about speaking native SBP/RBP/ATA at the periph level and native SPI/PATA/SATA/FCAL/SMP/USB at the transport level. So, before you continue to cast ignorant doubts on our approach and hawk your incomplete wares, please at least look at what is being done on our end, and make an attempt to ask some reasonable questions. Scott