From owner-freebsd-scsi@FreeBSD.ORG Fri Apr 20 18:59:39 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 7182B16A401 for ; Fri, 20 Apr 2007 18:59:39 +0000 (UTC) (envelope-from berni@ask-us.at) Received: from luxus.ask-us.at (luxus.ask-us.at [213.235.218.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0E50713C4B0 for ; Fri, 20 Apr 2007 18:59:38 +0000 (UTC) (envelope-from berni@ask-us.at) Received: from [192.168.0.129] ([213.129.242.166]) by luxus.ask-us.at with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 20:47:34 +0200 Message-ID: <46290AC6.9020608@ask-us.at> Date: Fri, 20 Apr 2007 20:47:34 +0200 From: Bernard Buri User-Agent: Thunderbird 1.5.0.10 (X11/20070309) MIME-Version: 1.0 References: <4628E0DE.2090103@samsco.org> In-Reply-To: <4628E0DE.2090103@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2007 18:47:34.0779 (UTC) FILETIME=[5C1AC4B0:01C7837C] 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 18:59:39 -0000 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* ?