Re: [Qemu-devel] [PATCH 0/7] poison TARGET_xxx for compile once object and header file cleanups

[Paolo Bonzini]

> > 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