From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 19:17:39 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 A70DC106566C; Fri, 5 Jun 2009 19:17:39 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D1258FC1D; Fri, 5 Jun 2009 19:17:39 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n55JHcHQ077307; Fri, 5 Jun 2009 12:17:39 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n55JHcLO077306; Fri, 5 Jun 2009 12:17:38 -0700 (PDT) Date: Fri, 5 Jun 2009 12:17:38 -0700 (PDT) From: Matthew Dillon Message-Id: <200906051917.n55JHcLO077306@apollo.backplane.com> To: Scott Long References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <4A2956C6.5070902@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 19:17:40 -0000 :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 Huh. Get up on the wrong side of the bed, Scott? Just remember who started making the shit comments this time. I have no interest with what FreeBSD is doing with CAM. My only interest vis-a-vie this thread are the AHCI driver efforts by the various BSDs, including ours. In particular, my interest is in NCQ, hot-plug support, and port multiplier support, as these three items can put SATA/AHCI on-par with dedicated SCSI controllers (at least once AHCI hardware revs past the original spec). It is something very important to all Open-Source OS projects as it consolidates the storage device driver spec and removes a huge thorn in the sides of all the projects with regards to the forward-support of new hardware. -- IMHO the only SCSI command non-SCSI devices have to fake-up is IDENTIFY. Everything else is a straight translation, and an easy one at that. Even SENSE doesn't need to be faked-up all that much, one just sets an AUTOSENSE flag bit and include the sense in the CCB. So interfacing to CAM is not really a big deal. The SCSI command set is the only cross-device portable command set that exists today, after all. The only problem I have with the original CAM is that it didn't use a dedicated thread for bus-reset/probe/scan/identify/attachment and detachment. That's the only reason the original API was such a bitch to deal with by device drivers. Fixing that fixes all the device interaction issues for attachment/detachment. The API doesn't actually change, but the recursive nature of the direct calls goes away and greatly simplifies device drivers. That's the only thing I see wrong with CAM, frankly. So I applaud your efforts on cleaning up the attach/detach stuff in FreeBSD, but it isn't my focus in this thread and not something I'm interested in doing for the DragonFly project, beyond what I mentioned above. Your comments are improper. -Matt Matthew Dillon