ron minnich wrote:
Another question.
Were we to follow the device object model, isn't it more proper to add a new device_operations struct member to devices to generate ACPI? Then we add another pass to the device code which walks the tree and each device can optionally create ACPI as it needs to. The first object is the mainboard, and this could do all the initial setup for the AML code generation.
The idea is definitely sound. But we're many steps before that, still. With our device model, and with our ACPI support.
There are large portions of a DSDT that are "not just the device tree", but a lot more. We can start feeding that stuff into our device tree. That's a thing I was yelling about already, too. But then we have a complicated device tree and a complicated generator. Seeing the complexity of ACPI in all its shades, I am slightly, temporarily scared
If we had this I think the weak symbol would not be needed.
Absolutely. But it means creating a new framework that is much more enhanced than what we have today.
This would drop very nicely in to v3: I would add a phase7_acpi struct member to device_operations.
It does sound a bit like v4. This is why it is so good.