From owner-freebsd-arch@FreeBSD.ORG Tue Jun 2 16:54:55 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54FB91065702 for ; Tue, 2 Jun 2009 16:54:55 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id D24F78FC20 for ; Tue, 2 Jun 2009 16:54:54 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 244687062; Tue, 02 Jun 2009 18:54:46 +0300 Message-ID: <4A254B45.8050800@mavhome.dp.ua> Date: Tue, 02 Jun 2009 18:54:45 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: freebsd-arch@freebsd.org, FreeBSD-Current Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Scott Long Subject: WIP: ATA to CAM integration X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 16:54:55 -0000 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 over SCSI (SAS) bus. ATAPI, same time, is the way to transport SCSI commands over ATA interface. So deep technologies interoperation pushes us to have similarly integrated infrastructures on software level. We are already have atapicam driver which is used to give CAM SCSI infrastructure access to ATAPI devices by translating drivers API and SCSI bus emulation. But it works only one way and also not perfect. Looking to all of this, I have decided to join Scott, to reanimate his 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. This project is going to have several main steps: - separate SCSI command set and SCSI bus management code from abstract CAM code and create abstract transport API (this step is mostly done now by Scott), - implement ATA command set device drivers, ATA bus management code and ATA host controller drivers (this step is now in progress by me), - update CAM to use newbus, to make it's components interoperation more transparent and formalized (this is now in planning and preparation stage), - when mentioned above finished, port the rest of existing ATA controller drivers one by one to the new world order. 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