From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 18:05:36 2008 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 6B66F16A41B for ; Wed, 2 Jan 2008 18:05:36 +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 27D4713C474 for ; Wed, 2 Jan 2008 18:05:36 +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 227032782-1834499 for multiple; Wed, 02 Jan 2008 13:03:11 -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 m02I4kCl018326; Wed, 2 Jan 2008 13:05:02 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marcel Moolenaar Date: Wed, 2 Jan 2008 13:03:31 -0500 User-Agent: KMail/1.9.6 References: <20080101.184909.195750479.imp@bsdimp.com> <3FAE3F14-C1B6-41BB-8DB0-A88C1DD09F66@mac.com> In-Reply-To: <3FAE3F14-C1B6-41BB-8DB0-A88C1DD09F66@mac.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200801021303.39518.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 02 Jan 2008 13:05:03 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5343/Wed Jan 2 12:41:01 2008 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: 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: Wed, 02 Jan 2008 18:05:36 -0000 On Tuesday 01 January 2008 11:47:59 pm Marcel Moolenaar wrote: > On Jan 1, 2008, at 5:49 PM, M. Warner Losh wrote: > > See devinfo -v on my system: > > isa0 > > ppc0 > > sc0 > > sio1 > > sio2 > > sio3 > > vga0 > > orm0 > > > > I do not have the sio or ppc drivers in my kernel at all, yet they > > appear to be bound to nodes in the tree by virtue of the hints that > > are present in device.hints. This is what allows the drivers to > > attach to nodes in the system if I were to dynamically load them. > > Let me use the above to better express my philosophical approach: > > The fact that that devinfo shows you that non-existent drivers are > bound to newbus nodes is exactly the problem with hints. Pre-newbus > the kernel configuration defined the instantiations and as such the > list of drivers that were needed. Both (i.e. the drivers and their > instantiations) came from a single description and could never be > out of sync. > Nowadays we have the drivers coming from the kernel configuration > (or dynamically through module loading) and instantiations coming > from the hints file. These two are typically out of sync with each > other. If hints were tentative, then we wouldn't have newbus nodes > for driver instantiations if the driver in question didn't exist. > > It's fundamentally wrong to instantiate a driver that doesn't exist. > I mean, what does that mean anyway? Agreed, and device.FOO would create an unknownX device (much like unprobed PNPBIOS or ACPI-enumerated devices) with a set of properties (if the bus impl uses properties to create devices and doesn't use them purely as additional metadata). For example, I actually figured that the default device.hints type stuff for COM1 would look like this: device.COM1.at="isa" device.COM1.port="0x3f8-0x3ff" device.COM1.irq=4 device.COM1.pnpid="PNP0500" which is what you get with ACPI/PnPBIOS. On i386/amd64 users would probably wish to bind it using something like: device.COM1.driver="sio" device.COM1.unit=0 but it wouldn't be required. Note that it would be nice to just say 'device.COM1.unit=0' and not specify a driver at all, but that would not be easy to implement in new-bus. -- John Baldwin