From owner-freebsd-scsi@FreeBSD.ORG Fri Apr 20 15:49:07 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 0A74E16A401 for ; Fri, 20 Apr 2007 15:49:07 +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 C1BCE13C4B0 for ; Fri, 20 Apr 2007 15:49:06 +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 l3KFn3u8053777 for ; Fri, 20 Apr 2007 09:49:03 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4628E0DE.2090103@samsco.org> Date: Fri, 20 Apr 2007 09:48:46 -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: scsi@freebsd.org 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 09:49:03 -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: Subject: 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 15:49:07 -0000 All, Now that the MPSAFE work is mostly done and settled, it's time to move onto the next phase of the overall work. NEWBUS integration + Transport modularization: ---------------------------------------------- CAM is centered around parallel SCSI. It has detailed knowledge of how buses, targets, and LUNs work in SCSI. Besides this knowledge being embedded in the core of CAM, it is not exported out to the NEWBUS framework. Running the "devinfo" command only shows the controller devices, not any of the topology underneath it. Camcontrol does show the topology, but that's a privileged command. My plan is to move the bus scanner and device probe functionality out of cam_xpt.c and into the scsi/scsi_xpt.c. As part of this move, buses, targets, devices, and peripherals will become newbus drivers, with the normal probe, attach, and detach vectors and semantics. The opaque cam_path, cam_eb, cam_et structures will become private to these newbus drivers. Access to the internals of these objects will be done through newbus interface methods. The XPT will retain knowledge of the cam_ed structure; keeping it opaque and accessible only though newbus methods would significantly slow down normal I/O operations. Topology will be built by parent objects allowing children to probe and attach themselves to child devices. Children will probe attributes such as bus type and device type to decide if they want to claim the device. Multiple peripheral devices will still be allowed to attach to devices, just as today. Topology will look something like this: nexus0 pcib0 pci0 sim0 scsibus0 target0 device0 da0 pass0 target1 device1 cd0 pass1 sim1 scsibus1 target2 device2 da1 pass2 I haven't decided yet if the newbus names of the bus, target, and devices will correspond to actual B:T:L enumeration numbers of if they'll just be assigned sequentially as they are discovered. Camcontrol will still show actual B:T:L enumeration, regardless of what newbus sees. The end result is that the XPT will be divided into 2 parts, one that manages topology and advertises devices, and another that manages the sim and device queues. This split will not affect the /dev/xpt0 device. Applications will still only see 1 XPT node, but xptioctl() will redirect transport-specific commands as needed. I expect most of this work to be transparent to userland CAM apps. There will likely be a small API change to SIMs to export the SIM newbus device node up so that children can be attached to it. 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? The SIM drivers for IDE/SATA will use the same interface as SCSI. They will be responsible for programming the controller, managing command timeouts, and performing transport level error detection and recovery, just like SCSI SIMs. Instead of a single monolithic driver that knows how to talk to dozens of very different controllers, support will be broken down into multiple SIMs, each targeted to individual controller families. I plan to write SIMs for AHCI, ICH2/3/4, and ICH5/6 controllers. There are no plans to retire the existing ATA driver anytime soon. It still contains the best support for tricky, buggy hardware, as well as older hardware. The future of these drivers will depend on how well they serve the community. Please let me know if you have any questions, objections, or suggestions. SCott