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
