From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 19:31:05 2007 Return-Path: Delivered-To: embedded@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DDB216A41B for ; Fri, 28 Dec 2007 19:31:05 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by mx1.freebsd.org (Postfix) with ESMTP id 2B93713C458 for ; Fri, 28 Dec 2007 19:31:05 +0000 (UTC) (envelope-from marcelm@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Fri, 28 Dec 2007 11:30:31 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Dec 2007 11:30:49 -0800 Received: from mini-g4.jnpr.net (nbaseer-t43.jnpr.net [172.24.104.164] (may be forged)) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lBSJUx959123; Fri, 28 Dec 2007 11:30:59 -0800 (PST) (envelope-from marcelm@juniper.net) Message-Id: From: Marcel Moolenaar To: "M. Warner Losh" In-Reply-To: <20071228.121213.-494094613.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Fri, 28 Dec 2007 11:30:59 -0800 References: <20071228.114559.-311937481.imp@bsdimp.com> <20071228.121213.-494094613.imp@bsdimp.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Dec 2007 19:30:49.0316 (UTC) FILETIME=[26AAB240:01C84988] Cc: 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 19:31:05 -0000 On Dec 28, 2007, at 11:12 AM, M. Warner Losh wrote: > If the ocpbus has a table of bus types, what's wrong with having it > directly assign the driver when it ads its children? It violates newbus in that drivers compete for a device. If the bus assigns the driver, then there's no competition possible. The fact that the bus is abstract should not mean that we should change its paradigm. > I guess I agree with you that we need an abstraction layer, but > quibble over the details. I especially object to creating an > enumeration where an actual device driver name would do. Agreed. We should not use device driver names. We could use strings instead of numbers, but other than that it's an abstract name or number that. > Plus the > problem is complicated because none of these devices is standard. > Sorry if my first reply came on a little strong on the enumeration > point. If there is a compelling argument for it, I'll listen, but it > isn't as if we have competing drivers for devices in this domain like > we did with sio vs uart. We should not abandon competition, because that would be a step away from generalization. Even though we're discussing this in the context of embedded systems, I don't see any reason why it couldn't equally apply to the LPC devices in PCs that are enumerated by ACPI... True, competition is not likely to be a often-used feature in an embedded system but modules may be and it's so much easier to deal with modules if you keep the existing paradigm and not have the bus driver assign device drivers. For in that case the bus driver need to be made aware that a new device driver was loaded and see if it's one it can assign to a device. -- Marcel Moolenaar marcelm@juniper.net