From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 22:12:39 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 29F7316A420; Fri, 28 Dec 2007 22:12:39 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by mx1.freebsd.org (Postfix) with ESMTP id EF33C13C4DB; Fri, 28 Dec 2007 22:12:38 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 14:12:35 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Dec 2007 13:49:50 -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 lBSLo0989364; Fri, 28 Dec 2007 13:50:00 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: <2ADEF6FE-DC65-489A-A948-81E1A0455CA7@juniper.net> From: Marcel Moolenaar To: John Baldwin In-Reply-To: <200712281500.55155.jhb@freebsd.org> 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 13:49:59 -0800 References: <20071228.114559.-311937481.imp@bsdimp.com> <200712281500.55155.jhb@freebsd.org> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 21:49:50.0603 (UTC) FILETIME=[927615B0:01C8499B] Cc: 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 22:12:39 -0000 On Dec 28, 2007, at 12:00 PM, John Baldwin wrote: >> 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. Just a comment: there's a lot of value in taking a look at language and DB theory. Both syntax and semantics can be very important properties in the applicability and success of the new description. Yes, we may want to be able to compile it into some binary form for embedding it into the kernel... For example: busses may nest and may need to be described. This is especially true in the embedded space. The e500 has a local bus within the CCSR, which may contain i2c busses for example. Using the hints-way of describing hardware is just not going to fly in that case, because you're still keying off of device names and unit numbers. Let that be a consequence of the metadata, not an integral part of... (device.COM1.* does exactly that). FYI, -- Marcel Moolenaar marcelm@juniper.net