On Wed, Jun 22, 2016 at 03:24:33PM +0200, Paolo Bonzini wrote: > > > On 22/06/2016 14:24, Efimov Vasily wrote: > > The patch series makes several devices closer to Qemu object model. > > > > I am developing a tool that automatize creation of device and machine > > models. > > > > Recently, I've take part in development of several models. And I noticed > > that > > a significant part of code is same. The examples are: > > - Each device represented by a header and a source. > > - The device or machine class is described by a set of callbacks containing > > in > > TypeInfo structure. > > - Each TypeInfo structure is accounted by a register function. > > - A register function is sheduled by a type_init macro. > > - Class and state structures of an inherited type are prepended by ones of > > the > > parent type. > > - A device must have VM state description. > > - A device or a machine can have properties. > > - A device can use internal APIs such as: timer, chardev, blockdev, IRQ, > > system bys memory and port mapping, PCI BARs, PCI MSI(X), etc. > > - A machine consists of devices and memory tree. Devices are linked by IRQs > > and > > buses and assigned property values. > > - All of the above should follow the Qemu coding style. > > > > For every listed item can be generated a stub code. All stubs can be > > generated > > with respect to each other forming compileable device (or machine). Ideally, > > a programmer have to implement custom device/machine logic and to assign > > meaningful names to variables, functions, macroses etc. using a refactoring > > tool. > > > > Of cource, a device/machine description for the tool has to be significantly > > smaller than the code the tool produced. A GUI constructor is preferred too. > > > > I've chosed Q35 machine to test the tool. The Q35 is one of the most > > complex boards. I have implemented 64-bit CPU, soft MMU, 1GB RAM, 1 HDD, > > PCI, USB machine variant. Most of devices is instantiated using the object > > model. Some logic (I/O port 80, I/O port F0, A20 line) is dedicated to new > > devices. The stubs for thay is also generated by the tool. > > > > In course of implementing Q35 I've noticed that some device models does not > > follow Qemu object model close enough. The patch series is desined to make > > them > > closer. > > > > Change log: > > > > v1 -> v2: > > A patch was added after 11-th one. The patch introduces function > > isa_connect_gpio_out needed by new version of consequent patch. > > > > 01: Git global option diff.renames was set true to generate the patch > > avoiding > > checkpatch.pl issues. > > > > 02, 05: qdev_prop_allow_set_link_before_realize is used instead of > > object_property_allow_set_link. > > > > 07, 08: Named GPIO was used for a20 line. > > > > 10, 11: The patches were rebased against the patch series > > https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg05619.html > > > > 10: Named GPIO is used for gsi. The name is "gsi" with alias ICH9_GPIO_GSI. > > > > 12: It's a new patch. The patch introduces function isa_connect_gpio_out. > > > > 13 (previously 12): Use isa_connect_gpio_out instead of isa_init_irq. > > I have queued patches 1-13, as said before I'm not sure of patch 14 and > I want to think about it some more. :) > > Paolo
You can add my Reviewed-by: Michael S. Tsirkin <m...@redhat.com> if you wish. I'll comment on 14 separately. -- MST
