Date: Tue, 1 Jan 2008 16:11:30 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <19740DB1-E759-4A61-8E1F-33AEAE74631E@mac.com> In-Reply-To: <20080101.135825.1943337000.imp@bsdimp.com> References: <2ADEF6FE-DC65-489A-A948-81E1A0455CA7@juniper.net> <200712311606.25424.jhb@freebsd.org> <CC4D41C0-7CD7-47A8-8DA0-523B38C65B9A@mac.com> <20080101.135825.1943337000.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 1, 2008, at 12:58 PM, M. Warner Losh wrote: > In message: <CC4D41C0-7CD7-47A8-8DA0-523B38C65B9A@mac.com> > Marcel Moolenaar <xcllnt@mac.com> writes: > : Let's just fix this right... > > In many ways, you are complaining about the same thing that I've > struggled with. Sometimes, hint.sio.0.addr=0x3e8 means 'bind > whichever of the enumerated COM ports lives at 3e8 to sio0' (eg, cross > binding of a device enumerated by other means to a driver/unit) and > sometimes it means 'you have a COM port whose resource starts at > 0x3e8'. Yes. We're going to use hints for too many things without making sure that a certain statement, assertion or rule is unambiguous. > I disagree with you that it is a fundamental flaw in the system, but > am always open to better suggestions at how to implement this stuff. > The hints were my first, best guess, and they have served us well. Yes, but... In the beginning, hints were used to let drivers know where to look for hardware. They were hints to the drivers so that drivers knew where to probe. Possibly before probing a fixed list of I/O ports where the ISA card could be configured to reside. The key point of that statement is that the drivers were already there. They were compiled-in by virtue of the kernel configuration that already included bus attachment information and resource lists. The hints didn't cause the instantiation of a driver! This is not what's happening now. Hints cause driver instantiations and as such are much more significant than originally designed. They stopped being hints and turned into something much less well- defined. > We > are at the point now where we must expand them either as John has > outlined, or we need to scrap them entirely in favor of something > better. What we cannot do is let the promise of something better that > isn't really being worked on stop us from expanding what we have. It has nothing to do with the promise of something better. It has everything to do with understanding of the problems. Put differently: extending what you have because you don't want to put in the effort of understanding the problem and working out how such could be solved is ultimately worse, because you end up with something that's not broken enough to fix but which will always cause you problems -- problems you can only accept because the alternative was not even considered. > Do you have something specific in mind that we can start working on > some kind of design document against? I don't have a design document, but I have mentioned in various emails what I think we should be doing. Unless there's sufficient agreement on the rough course of action will I be working on details. > It is OK if that's a series of > conversations, but we have to get off the inflection point we're at > now: No, you can't expand what's there, and there's no clearly > articulated 'something better'. I have been conversing. I have been expression my point of view. What I have not seen, until now, is an actual statement of intend to just look at it from a different angle and see if we can come up with some set of requirements. Everything so far has been pivoting around hints. We have them and we're extending them. What about letting the discussion pivot around the problems we're trying to solve and once we have that fleshed out see if and how we can use hints before we realize that it's better to start from scratch? > So if you could take a few minutes and write up a straw-man proposal > for what you see as doing it right, I think that would get us toward a > solution... As said previously in many of the emails on the subject: We need to seperate out the different uses or needs and come up with a layered solution of some sorts: The lowest layer is enumeration of the hardware. This, typically, is a combination of hardware self-enumeration, firmware-based enumeration or pure software-based enumeration (i.e. the proverbial hardcoded tables). On top of the hardware layer we have the newbus infrastructure layer that, given a view of the hardware provided by the hardware layer, constructs the newbus device tree and provides for wiring before the generic probe/attach sequence starts. On top of the newbus layer are the devices themselves. They use the newbus layer to obtain their resources and fetch device-driver specific settings. For the hardware layer we need a description of the hardware. The keying information is resource location or device path. The newbus layer needs a description of the wiring and/or routing. The keying information is resource location or device path. The device layer needs a description of per-instance driver options. The keying information is resource location or device path, combined with driver and unit number. Concretely: A simplified hardware description could be (key=ioport): ioport=0x3f8 -> iosize=8, type=UART, irq=4 A description for prewiring could be: (key=ioport): ioport=0x3f8 -> driver=sio, unit=0 A description for the driver could be (key=ioport_driver+unit): ioport=0x3f8, driver=sio, unit=0 -> fifosize=32 A serial console is defined alongside the hardware description. You don't define the hardware, so it shouldn't be part of it. You do describe intended use of the hardware, so it's should be in the hardware layer where you define it. As such, the serial console is keyed off of the ioport in the example above: ioport=0x3f8 -> what=console, baudrate=9600 This all makes it possible to replace the sio driver with uart and have a different set of driver descriptions for the same hardware: ioport=0x3f8, driver=uart, unit=any, clock=1843200 You also know that competely removing the newbus information (i.e. the prewiring) will not affect the view of the hardware. It will only affect which drivers get attached and which units are being assigned. You also know that if the (view of the) hardware changes, your newbus description will match where possible and be ignored where appropriate. This mean that if you previously had a newbus description that prewires a network interface to, say, bge2 and you removed the interface, you simply wont use the prewiring. It will later be used when the interface is added back. Apply RDB theory and you can start constructing the tables. From the tables you can derive a more suitable way of specifying the information and having it used early on by a kernel. Another thing to keep in mind is that any low-level console, whether serial or otherwise and whether using legacy devices or USB or firewire needs access to the hardware before we have newbus up-and running. That's why the console specification would be in the hardware decsription layer: you don't have newbus, no prewiring and no assigned devices. Moving forward, we should take OFW or EFI as an example of how you can describe hardware and morph that into something that allows us to: o compile into some binary form for compactness o can be loaded as a module or specified at the loader prompt. Once we have that, newbus descriptions (for prewiring) are trivially added. Driver descriptions (or more accurately driver directives) should be more like var=value lines because of the wide and unstructured nature of what drivers may need. -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19740DB1-E759-4A61-8E1F-33AEAE74631E>