From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 22:14:13 2007 Return-Path: Delivered-To: embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 950B616A419 for ; Fri, 28 Dec 2007 22:14:13 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by mx1.freebsd.org (Postfix) with ESMTP id 73CCA13C45A for ; Fri, 28 Dec 2007 22:14:13 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 14:14:12 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Dec 2007 14:12:07 -0800 Received: from mini-g4.jnpr.net (mini-g4.jnpr.net [172.24.104.164]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBSMCH994420; Fri, 28 Dec 2007 14:12:17 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: <1EDE7CF9-586A-41CE-9B05-1E4A6431653D@juniper.net> From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.134154.1136083975.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 14:12:17 -0800 References: <20071228.125020.-1962668065.imp@bsdimp.com> <595F307F-8FC5-48D5-A69C-84660A768F23@juniper.net> <20071228.134154.1136083975.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 22:12:07.0210 (UTC) FILETIME=[AF2420A0:01C8499E] Cc: embedded@FreeBSD.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 22:14:13 -0000 On Dec 28, 2007, at 12:41 PM, M. Warner Losh wrote: > : > FreeBSD has two models for device enumeration. One is where the > : > parent bus decides, by whatever means, and one where the device > itself > : > has enough information to allow the driver to decide. I think > that > : > trying to shoe-horn the second model into a situation where the > first > : > model is actually better would be a disservice. > : > : When would the first be better? > > When there's no information about the children in the children. When is there information about the children in the children? Put differently: the only thing a PCI device driver knows is that if the vendor is X and the device is Y, it can be used with this driver. That's circumstantial. The same kind of circumstantial information can be synthesized for any and all busses that need external enumeration. It's merely a way of consuming the information. I propose that device drivers are the ultimate authority on wether they attach or not. Not the busses. > Unlike PCI, in this domain these devices don't have a device ID. True. We synthesize IDs for drivers to match against. Those IDs have nothing to do with hardware. It's just an agreement between the abstract bus driver and the device driver so that the bus knows how to flag a child for use by said driver. It's just an indirection. > With an enumeration like you suggest, one would need to create an > enumeration for each and every one of these things, compile it into > the kernel and then have some kind of translation layer that we get > for free today with newbus and bus_enumerate_hinted_bus(). I think you misunderstand the concept. -- Marcel Moolenaar marcelm@juniper.net