Date: Fri, 28 Dec 2007 11:30:59 -0800 From: Marcel Moolenaar <marcelm@juniper.net> To: "M. Warner Losh" <imp@BSDIMP.COM> Cc: embedded@FreeBSD.ORG Subject: Re: ocpbus(4) Message-ID: <C95AFF48-2C06-40FA-BDB4-C46011EECCF3@juniper.net> In-Reply-To: <20071228.121213.-494094613.imp@bsdimp.com> References: <B56F8F3C-7872-47B9-8154-1C08F5BEEA3D@juniper.net> <20071228.114559.-311937481.imp@bsdimp.com> <20071228.121213.-494094613.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C95AFF48-2C06-40FA-BDB4-C46011EECCF3>