On Sat, Oct 16, 2010 at 12:24:12PM +0200, Martin Husemann wrote: > The main difference that I understood seems to be what you call virtual > and natural device trees: in OF world we guide the whole autoconfig tree > along the OF device tree, with differences close to the leafs (i.e. the > scsibus der Mouse mentioned). At every point during autoconfig we can > make sure to have enough OF information already available during the > device_register() call. The only problem we ran into so far, IIRC, is the > id of FC disks for boot device detection, but we worked around that pretty > easily.
This seems to be what is needed on x86 as well. The only way to eliminate such things as PCI_BUS_FIXUP etc. and several existing bus_space(9) conflicts is probably to parse the firmware tree as the first thing, and then utilize this information at each attachment step. This is exactly what I meant by noting that we tend to think this backwards; perhaps ACPI should drive the autoconfiguration, not vice versa. It is problematic to think that we can continue as business as usual, and then ACPI drivers go and seek their real counterparts that have been attached without using ACPI in the first place. Another thing is the actual device tree. For instance, currently, even with the fine work done with pmf(9), in some corner cases we may power off a device before its children are turned off because the device tree is partially arbitrary. > I don't think the auto-config time and in/out distinction you draw > realy is that relevant. With OF we still can call firmware methods any > time later, and we could take callbacks (though I don't think there are > any relevant). ACPI seems to do more in that area, but I fail to see the > fundamental problem, assuming you manage to get ACPI device tree traversal > and autoconfig tree building "synchronized" somehow (i.e. have all needed > ACPI information available for device_register()). There are certain firmware methods that can be assumed to be universal. Examples include so-called power resources, but also wake-up interrupts are done via the firmware (think: WoL, suspending devices at runtime, etc.). This means that we likely need to touch such essentials as device_t in order to device_register() callbacks; we have no a priori knowledge about the drivers for which the vendor has implemented such firmware methods. But then we have cases like acpicpu(4). Here the firmware may actually dynamically at run-time change the I/O addresses we ought to write to or change the MSR values to be written, observing bus activity is done via the firmware, and so forth. While this is not the best of example because CPU is MD, there are other comparable cases with MI drivers. Particularly, as is seen with acpivga(4), several ACPI-specific interrupts ("notifys") need to be delivered to real drivers. - Jukka.