On Fri, May 01, 2020 at 12:57:54PM -0300, Daniel Henrique Barboza wrote: > > > 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. Yes, it was not intended to be tied to QEMU's specific implementation either. It should be a generic modelling / addressing system. > > 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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
