On 5/1/20 7:40 AM, Daniel P. Berrangé wrote:
On Thu, Apr 30, 2020 at 09:00:51PM -0300, Daniel Henrique Barboza wrote:
My initial plan is to get the logic/APIs design from Libvirt, rename
them in a Gopher fashion, re-code it with Go and call it a day :)
That is really not a way I would like to go, as that means we immediately
inherit the design bias of the current libvirt code. The goal is to be
able to replace current libvirt code eventually, but I don't want it to
just be a clone of that code, as I think it misses the opportunity to
try to design something better than what we have done.
As a particular example.. the current placement code has no conceptual
model of machine types present in QEMU. We've just got many "if" tests
that take different codepaths based on heuristics about the machine
type. I would like the new API to have an explicit conceptual model
of each machine type we intend to support. ie it should have full
representation of the default topology of devices that are mandated
by the machine type. Ideally this modelling should be extendable
without having to write code in the placement model. ie we should
be able to load a "i440fx.yaml" file describing the i440fx machine
type and the placement logic "just works". We should not have any
tests like "if (is i440fx)" in the code itself.
That's a sound idea. I'd say that instead of basing yourselves in the QEMU
machine types addressing we should aim in implementing he machine specification
instead, even as a long term goal.
E.G let's say that Libvirt wants addressing services for a hotplug in a QEMU
i440fx guest. Instead of devaddr implementing "this is how the i440fx
addressing works
in QEMU", devaddr should be more concerned about "this is how the i440fx
processor
addressing works". If QEMU does additional/different things on top of that then
qemu_driver.c should operate on that. This allows devaddr to be hypervisor
agnostic.
The libvirt code shows us the range of features we need to support at
least though.
I'll see if I can take a look in all the "if (pseries)" in Libvirt device
addressing code
to get an idea of how a PowerPC addressing model would work related to x86.
DHB
Regards,
Daniel
