From owner-freebsd-scsi@FreeBSD.ORG Fri Apr 20 20:28:14 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E71F016A401 for ; Fri, 20 Apr 2007 20:28:14 +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 92DE713C45D for ; Fri, 20 Apr 2007 20:28:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l3KKS7TW058797; Fri, 20 Apr 2007 14:28:07 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46292245.3030900@samsco.org> Date: Fri, 20 Apr 2007 14:27:49 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Bernard Buri References: <4628E0DE.2090103@samsco.org> <46290AC6.9020608@ask-us.at> In-Reply-To: <46290AC6.9020608@ask-us.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 20 Apr 2007 14:28:07 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: scsi@freebsd.org Subject: Re: Upcoming plans for CAM X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 20:28:15 -0000 Bernard Buri wrote: > Scott Long wrote: >> All, >> >> Now that the MPSAFE work is mostly done and settled, it's time to move >> onto the next phase of the overall work. >> > this is great news! > I've been working with the CAM layer in my last project, and I loved it. > It is the most advanced scsi stack I've seen, so I'm glad it gets some > refinement now. > >> ... >> SATA and IDE transports, ATA protocol >> ------------------------------------- >> >> The transport modularization work described above will allow non-SCSI >> transports to be easily added. So, the next step is the long-promised >> unification with IDE and SATA. Instead of hacks like atapicam and >> atacam that try to force IDE/SATA into the SCSI model, a whole new >> subtransport will be written that understands the topology and nature of >> the devices, as well as natively understanding the ATA command set. >> >> There are still some interesting design questions that need to be >> answered here. SATA controllers essentially use a star topology instead >> of a bus topology. So does it make sense to treat all devices as each >> having a private bus, or is it better to have a single virtual bus? >> Also, ATAPI devices basically speak the SCSI protocol so they'll attach >> to things like the 'cd' driver, but ATA disks speak ATA, which is very >> different from SCSI. Should they get their own unique peripheral >> device, or should they be part of the 'da' device? If they get their >> own peripheral device, should they still generate '/dev/da' device >> nodes, or should they retain the current '/dev/ad' naming? >> > I think that for the user, the device name doesn't really make a > difference. Like with network interface cards, it is not a problem that > some of them show up as fxp*, while others show up as myk*. As long as > there is not a separate fxpconfig and mykconfig tool. > > I think for the way cam is desigend right now, it is more intuitive to > have separate device names. > > In fact, I don't know much about ATA disks. I recognized recently, that > SATA disks show up as /dev/sdX on linux while PATA disks show up as > /dev/hdX. And SATA disks are said to be compatible to serial attached > scsi. Does it mean that only PATA disks will be /dev/ad* ? > First of all, a distinction needs to be recognized between the transport and the protocol. The transport basically describes how the device is connected to the system. It could be a SATA bus, it could be a SAS expander, it could be a parallel SCSI bus, etc. The protocol describes what language the device speaks. That could be SBC (SCSI Block commands), MMC, ATA, etc. Both IDE and SATA disks speak the ATA command protocol, regardless of how they are attached to the system. However, SATA disks can be on a SATA transport or on a SAS transport. The changes I'm proposing address exactly this; no longer will CAM be purely parallel SCSI specific with hacks to support other things, it'll recognize the different transports and protocols and allow them to be mixed together in whatever way the SIM allows. On the Linux side of things, they're basically kinda sorta doing the same thing, though less elegantly. They wrote a SATA shim for SCSI a few years ago (libata), and are now in the process of trying to expand that to do the same modularization of the transport that I'm proposing. However, they're stopping at only supporting SATA under this new scheme, leaving all IDE to the old hd driver. I intend to support IDE since it's still a very common transport, especially for CDROMs. As for the device naming issue, one of the original intentions of CAM was to unifying the naming scheme. A disk should be a disk, it shouldn't matter what the transport or protocol is. Those are details that should get handled transparently. At the same time, the situation in linux is showing that users are getting unhappy with traditional device names changing. Linux is making it harder than it needs to be because of how they name IDE CDROMs, but that's baggage that is unique to Linux, not FreeBSD. But, it's still a consideration that should not be overlooked. Scott