From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 17:36:28 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69BCE106566C; Sat, 13 Sep 2008 17:36:28 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 030798FC12; Sat, 13 Sep 2008 17:36:22 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m8DH8t9d043850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 13 Sep 2008 19:08:56 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m8DH8p1K099805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Sep 2008 19:08:51 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m8DH8pxq092238; Sat, 13 Sep 2008 19:08:51 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m8DH8kuv092237; Sat, 13 Sep 2008 19:08:46 +0200 (CEST) (envelope-from ticso) Date: Sat, 13 Sep 2008 19:08:45 +0200 From: Bernd Walter To: Julian Elischer Message-ID: <20080913170845.GT1147@cicely7.cicely.de> References: <200809112044.43749.hselasky@c2i.net> <48C9977C.2030104@samsco.org> <48CAB37F.50002@samsco.org> <20080912.145724.-1750800872.imp@bsdimp.com> <20080912150630.C39726@pooker.samsco.org> <48CB3D09.4050908@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48CB3D09.4050908@elischer.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.068, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: rink@freebsd.org, current@freebsd.org, fbsd-current@mawer.org, freebsd-usb@freebsd.org, volker@vwsoft.com, hselasky@c2i.net, "M. Warner Losh" Subject: Re: "legacy" usb stack fixes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2008 17:36:28 -0000 On Fri, Sep 12, 2008 at 09:09:45PM -0700, Julian Elischer wrote: > Scott Long wrote: > >On Fri, 12 Sep 2008, M. Warner Losh wrote: > >>Yes. A SIM will serialize all operations, and the most logical place > >>for that is the computer <-> usb interface, which is the host > >>controller. So having one SIM per host controller would be the > >>optimal placement. Having one SIM per usb device doesn't result in > >>any more real parallelism because the host controller necessarily > >>serializes things because of how USB is defined... > > > >Correct. Another argument for having a SIM per controller/bus and not > >per target is that the SIM is responsible for managing all resources on a > >controller. USB is still a bus topology, and thus certain resources are > >finite and shared, be they bandwidth, arbitration, or concurrency. > >Granted, USB is simple enough that it doesn't give you much control over > >these resources, but having the SIM be at the target level gives the > >system even less control and visibility. If a future enhancement to USB > >grows the ability to do useful things like more concurrency, it'll be > >essential for the SIM to have a controller-wide view of this. > > cam/umass used to have a SIM per USB bus but it got changed sometime > around 1999-2001 from memory. It was haled at the time as a great step > forward when each device got its own SIM but I could never work out why. I did the change at that time and it was not fully agreed by everyone. There was a single global SIM for all umass devices. One of the limitations was that each umass device was represented with a single ID and the maxid was hardcoded. The reason for the change however was that the SIM wasn't reprobed correctly and a manual camcontrol rescan was required under some conditions - especially with multi LUN devices. None of the persons who disagreed with the change switched it back to single SIM with a better fix. > it did solve some problems though I forget what they where. Yes it did, but it could have been fixed in a different way with a single SIM as well. At that time I thought multi SIM would be good idea, but I'm not that sure anymore, since there are also some good arguments against. One of the positive effects is that it is a bit easier to get from the USB device notified by devd to the CAM device to automatically handle things if e.g. your picture camera is connected or start syncing important data if your backup disk gets connected. Another point that I saw was using USB to SCSI converters, where you can have a single USB device owning a complete SCSI bus, but those devices are rare and not umass compliant. All in all the multi SIM as we have today is more a workaround for different other problems. In short: the original reasons for the change are not strong enough to keep it that way. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.