From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 20:48:40 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 7FCC316A417 for ; Fri, 28 Dec 2007 20:48:40 +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 3D1D113C4D5 for ; Fri, 28 Dec 2007 20:48:40 +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 226432420-1834499 for multiple; Fri, 28 Dec 2007 15:50:42 -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 lBSKm38k064655; Fri, 28 Dec 2007 15:48:23 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Fri, 28 Dec 2007 15:46:20 -0500 User-Agent: KMail/1.9.6 References: <20071228.114559.-311937481.imp@bsdimp.com> <200712281500.55155.jhb@freebsd.org> <20071228.132951.-432836769.imp@bsdimp.com> In-Reply-To: <20071228.132951.-432836769.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712281546.21288.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:48:24 -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: marcelm@juniper.net, freebsd-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 20:48:40 -0000 On Friday 28 December 2007 03:29:51 pm M. Warner Losh wrote: > In message: <200712281500.55155.jhb@freebsd.org> > John Baldwin writes: > : 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. > > How does one separate the topological information from the > proscriptive information? Eg, is the irq=4 an instruction to the > driver to use IRQ 4 for the device (proscriptive), or is it an > instruction to the bus to help locate COM1 (topological). The bus chooses. For the isa0 case it's complex, but it would basically work the way my current hint-wiring patches work. The acpi0 (ACPI) or isa0 (non-ACPI and using PNPBIOS) busses would use the resourcse to match COM1 to an existing device if possible. isa0 then does a second pass to actually add device_t's for any "hint" devices that weren't already matched. For smarter busses like pci(4) and usb(4) the topological info would be much more restrictive. pci(4) could probably just match solely on the "at" attribute and require it to specify the bus/slot/func (and optionally domain). > : 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 > > Same question here. If the first one was 'device.FOO.at=pci' then > what would the other two things mean, especially if there was a > driver/unit forced for this device? pci(4) wouldn't allow for just "pci", it would only match a set of properties for a device hard-wired to a specific location. > : 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'. > > Again, the same questions: what parts of this are topological and what > parts proscriptive? See above. Look at the hints wiring patch I had. Basically you are doing 's/hint.sio.0/device.COM1/'. It actually works out the same. Once you can assign named properties to devices then wiring becomes a separate property. > : 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. > > We already have similar interfaces to get the hinted properties... > What would the translation be. This would replace hints and resource_*(). resource_*() might still hang around in some form for things that use hints w/o new-bus such as SCSI wiring. > Also, I think that even though this is mildly relevant for the ocpbus > discussion, we shouldn't let ourselves get sidetracked by it. Well, I think it is relevant to the idea of creating a set of abstract-but-not-really ivars to try to replace hints. :-P -- John Baldwin