I don't see it at all as a temporary measure. In theory, only devices
compiled per-target would need access to CPUState, that's true.
There is no need for any device to have access to CPUState fields.
That's why this patch defines CPUState as opaque (i.e. incomplete).
Granted, an opaque CPUState plus a bunch of accessors is not any better
than a fully-visible CPUState, if the accessors are very much tied to
that particular CPUState type. (But then, we also agree it is also a
tiny little bit better than void*).
First, converting devices such as APIC to qdev requires knowledge of
CPUState in qdev, unless you want to keep DEFINE_PROP_PTR (whose removal is
much more interesting) or sweep it under the void* blanket. PICs are likely
to have CPUState members, e.g. hw/pxa2xx_pic.c (and BTW indirect access via
functions to these fields is making emulation a little bit slower).
One way to clean up PICs would be to use qemu_irq to signal CPU
interrupts, but there are probably others.
In the end the devices will be wired to a particular CPU and these
"wires" will likely be more complex than a 1-bit IRQ, so qemu_irq only
makes limited sense as it is now.
What you have to pass may be simply a 32-bit value as in hw/etraxfs_pic,
or a more complicated payload as in apic_bus_deliver, but anyway at some
point you'll be coupling either:
- the device to the CPU, as it happens now. As above, the CPU may be
accessed via void* and functions, or via fields directly, but in any
case the coupling is there.
- the CPU to the device. If you used qemu_irq that would be the most
likely outcome: the CPU knows about some DeviceState, and it downcasts
it to an expected device type in the IRQ handler. Again, you only have
an illusion of decoupling and, given the lengthy discussion about IRQ
payloads on qemu-devel only a few weeks ago, I'm not optimist it's going
to go away.
Also, for things compiled in libhw that are not part of device code,
requiring knowledge of CPUState is absolutely not problematic and the only
alternative loses type-safety and so it is inferior.
Completely untrue. Devices (whether part of libhw etc. or not) have no
need (from architectural point of view) to access CPUState contents.
It's clearly problematic. It's also possible to get type safety
without CPUState references in the devices.
I explicitly said "things compiled in libhw that are not part of device
code", most of which you added.
Anyway, thanks for the review and the (partial) ack. I'll rework the
patch series and resend.
Paolo
