Date: Fri, 28 Dec 2007 15:00:54 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-embedded@freebsd.org Cc: Marcel Moolenaar <marcelm@juniper.net> Subject: Re: ocpbus(4) Message-ID: <200712281500.55155.jhb@freebsd.org> In-Reply-To: <B5E9CBD1-0F16-422C-9AFA-CC33D988630C@juniper.net> References: <B56F8F3C-7872-47B9-8154-1C08F5BEEA3D@juniper.net> <20071228.114559.-311937481.imp@bsdimp.com> <B5E9CBD1-0F16-422C-9AFA-CC33D988630C@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.<property>=<value> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712281500.55155.jhb>