From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 20:27:46 2007 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82A4716A417 for ; Fri, 28 Dec 2007 20:27:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 3A93413C4EA for ; Fri, 28 Dec 2007 20:27:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 226427182-1834499 for multiple; Fri, 28 Dec 2007 15:13:44 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id lBSKBQqA064381; Fri, 28 Dec 2007 15:11:26 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-embedded@freebsd.org Date: Fri, 28 Dec 2007 15:00:54 -0500 User-Agent: KMail/1.9.6 References: <20071228.114559.-311937481.imp@bsdimp.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712281500.55155.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 28 Dec 2007 15:11:26 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5278/Fri Dec 28 11:55:36 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Marcel Moolenaar 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 20:27:46 -0000 On Friday 28 December 2007 02:16:43 pm Marcel Moolenaar wrote: > > : Q1: Do people think it's worthwhile to pursue a generic > > : ocpbus(4) definition? > > > > Generally, yes. In fact, I've done a bunch of things with what I've > > called obio (On Board I/O) that does similar things, but relies > > entirely on hints to do the job. Since that's how we do things > > elsewhere, this seems like a reasonable approach. If we move to doing > > things differently, then we can talk about that. > > Hints can be used to implement the device tree or > device list, but is rather limited. I'd like us to > implement something richer in the future. For that > reason I don't want to expose hints to the driver, > but rather abstract the implementation of the device > tree or the device list behind IVARs. That makes it > possible to implement the "bus" in many different > ways without having to change the device drivers that > attach to the bus. So to jump in here. I've been thinking more since the last hints debacle and am thinking of replacing hints with the generic device metadata we'd discussed some at the end of the last thread: device.FOO.= where any driver or unit wiring is a new property rather than encoded into FOO's name. Thus: device.COM1.at=isa0 device.COM1.irq=4 device.COM1.port=0x3f8 device.COM1.driver=sio device.COM1.unit=0 or some such. There would be a new-bus level framework to enumerate the various devices that have properties and bus drivers would "claim" a device and bind it to a child device_t. Each bus could then expose the properties as it saw fit. For example, if you had this: device.FOO.at=pci4.5.0 device.FOO.vendor=0x5555 device.FOO.device=0x1212 then the PCI bus could use that to override what gets returned via the vendor, device, and devid IVARs used in probing. You could still implement the bus_enumerate_hinted_children() API using this alternate backend. Also, fwiw I'm thinking of having a 'device' command in the loader that is a bit of a frontend so you can do things like: 'device COM1 at isa0 irq 4 console' that might translate into setting 'at=isa0', 'irq=4', 'console=1'. I also think there might be a generic way to get at any properties associated with a device_t by doing: int property_get_str(device_t dev, const char *name, char *buf, size_t buflen); int property_get_bool(device_t dev, const char *name, int *val); int property_get_int(device_t dev, const char *name, int *val); etc. Maybe devprop_* instead, but you get the idea. -- John Baldwin