From owner-freebsd-embedded@FreeBSD.ORG Wed Jan 2 01:49:55 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 74FA616A417; Wed, 2 Jan 2008 01:49:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E24E213C45A; Wed, 2 Jan 2008 01:49:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id m021mwMK039563; Tue, 1 Jan 2008 18:48:58 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 01 Jan 2008 18:49:09 -0700 (MST) Message-Id: <20080101.184909.195750479.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: <19740DB1-E759-4A61-8E1F-33AEAE74631E@mac.com> References: <20080101.135825.1943337000.imp@bsdimp.com> <19740DB1-E759-4A61-8E1F-33AEAE74631E@mac.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 01:49:55 -0000 Marcel, thanks for taking the time to engage with me on this. The first part of my message does correct a couple of misconceptions you have, and may sound a bit argumentative. Sorry if it does. The second part looks to ways to incorporate your ideas into a good replacement scheme that would allow for richer expression. In message: <19740DB1-E759-4A61-8E1F-33AEAE74631E@mac.com> Marcel Moolenaar writes: : : On Jan 1, 2008, at 12:58 PM, M. Warner Losh wrote: : : > In message: : > Marcel Moolenaar 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. In the beginning (when newbus was introduce circa 3.0) they were used by the busses to assign resources to the drivers they were adding. It just turned out that the 'hints' were compiled into tables the drivers used. In 4.x, the hints migrated from the config file to a text file called typically device.hints. Throughout these underlying changes, the drivers have never really known about resource hints. The bus is the only thing that parses and consumes them (the busses were changed from using the compiled in tables to using hints in 4.0). The ISA bus used to be the only one that looked for the 'at' key with a value of 'isa' or 'isa0', and it used that to populate the children on the isa bus. The drivers whose nodes are added to the tree as hints have no idea that the resources came from hints or from some other enumeration mechanism. They just call bus_alloc_resource and they get the resource. The removal of probing a fixed list of I/O ports happened at the same time that newbus was introduced into the system. There may have been one or two stragglers after we did the bulk of this work, but nearly all of it was done when newbus was committed. 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. : 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! Actually, they did. You are confusing the code that's in the kernel to device nodes in the tree. The hints will *ALWAYS* be there, even when the appropriate driver isn't compiled into the tree. The device nodes in the device tree will be there, unattached. : 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. What is happening now is what has always happened. : > 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. We can't let your aesthetic objections to the system that's basically working today block further efforts. I hate to be so blunt about it, but we as a project have gone more with a rough consensus and working code over a pie in the sky perfect design with no implementation. Having said that, I'm willing to consider an alternative, but it has to handle the functionality that hints handle today. : > 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? The reason for that is that hints are basically working. If there's another scheme that can work, then we can move to it, but until then we have hints and we shouldn't be inventing hacks to get around the fact that hints are apparently misunderstood. I'm happy to work with you on a better scheme from scratch, but we have to keep in mind that we need certain functionality today. : > 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. I think you are mixing layers here. The newbus layer is in charge of assigning unit numbers. The driver shouldn't know anything at all about device paths or resources that bind it to a unit. It is told 'probe this node and your unit number is X' and the driver has to like it. There's a kludge in place now that I've removed in my tree for sio so that the serial port would get the right unit number, but that has always been considered an aberration that should be eliminated at the first change possible. : 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 I think you are mixing the levels of abstraction again. We don't want the hardware locators to be used once the newbus bus has assigned a unit and driver to the device. This is the main problem that I have with this design: it blurs the line between the hardware location and other ways of locating a device. : 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. I need more details than this. I hate to keep pressing for more details, but I think that your view of the world leads to the same blurring of abstraction levels that we have with hints today. : 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. If we can make consoles regular in the system, so much the better, but we shouldn't let their needs drive the design. Consoles are a special case today, and if they remain a special case, then I'm OK with that. It may be the best way to cope with consoles is to have a 'console' record that each of the possible consoles lookup. Those consoles that match would bid for which one wins (or we support multiple ones, it doesn't really matter to me). The matching console would then use the value from the console key as a set of key=value pairs to give it what it needs to do its job. : 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. So the only significant change from the current hints scheme is just the key lookup for the device? right now the only key you can use is the device name and unit for a given variable. Your scheme would allow for more types of lookups than just the one key we currently provide. Or put another way each device node in the newbus tree would have some attributes. One would use those attributes, in addition to the name/number to look up other attributes of the device. I like this idea in theory. I'd like to explore ways to make it more concrete for both the device driver interface for drivers (including console drivers) as well as for busses that have to deal with wiring device driver nodes in the newbus tree to unit numbers, drivers and actual hardware. I'll be out in the bay area in a couple of weeks. I think we're doing some talking past each other in this email exchange. Maybe we could get together while I'm out there and go over your ideas and see how we can move to that kind of system. I think this might help us get the ideas into a more concrete form than doing it just through email. Are you up for that? If so, I can send you the dates I'm available... Warner