On 03/15/2011 09:53 AM, Chris Wright wrote:
QAPI -- http://wiki.qemu.org/Features/QAPI
- please review!
- Anthony would like to see feedback and plans to commit in a week
(assuming agreement and no major issues in review)
- some concern about the maintainability of code generation
- but still nothing concrete on the list, need to review and discuss
on the list
- some concern that implementation details may change the wire protocol
- introduces a new mechanism for new signals (mask by default and
enabled explicitly)
- disagreement over when/how to introduce new extensions
I'm going to try to figure out a better way to do this. For the short
term, we don't have an immediate need for the new signaling mechanism
but I think I've been adequately convinced that we need something better
for 0.15.
- libvirt feedback?
- no protocol level changes
- old and new versions are testable with test suite and proves this
- c library implementation is critical to have unit tests and test
driven development
- thread safe?
- no shared state, no statics.
- threading model requires lock for the qmp session
- licensiing?
- LGPL
- forwards/backwards compat?
- designed with that in mind see wiki:
http://wiki.qemu.org/Features/QAPI
One neat feature of libqmp is that once libvirt has a better QMP
passthrough interface, we can create a QmpSession that uses libvirt. It
would look something like:
QmpSession *libqmp_session_new_libvirt(virDomainPtr dom);
The QmpSession returned by this call can then be used with all of the
libqmp interfaces. This means we can still exercise our test suite with
a guest launched through libvirt. It also should make the libvirt pass
through interface a bit easier to consume by third parties.
QCFG -- http://wiki.qemu.org/Features/QCFG
- command line args translation to objects is complex and buggy
- schema + code generator to formalize this
- formally describe each command line option and generate code
to build and validate objects
- provides systematic way to document command line options
- automatically
- device_add does multiple conversions to go from qmp to qemuopts to
objects
- move to basic c structures, and autogenerated marshalling code
- no plan to do this work soon, late in 0.15 cycle
- same as qapi, fork a tree, do mass conversion and merge for 0.16 cycle
- qmp server mode to take all configuation commands before actually
starting the guest
- can provide a config file
- qdev...
- could just bridge to setting and getting qdev properties
- OR get to point where device objects go directly to qdev device init
So we'd do something like:
{ 'device': 'ISASerial', 'properties': { 'iobase': 'int', 'irq': 'int',
'chardev': 'CharDriverState' } }
And we can document all of the parameters in the same fashion as
everything else. We can extract that documentation to provide QMP-level
documentation, CLI-level documentation, and even online documentation
for qdev.
The only question in my mind is what the C interface ought to be. It
could be:
DeviceState * qdev_create_isa_serial(ISASerialProperties *props, Error
**errp);
And:
DeviceState * libqmp_qdev_create_isa_serial(ISASerialProperties *props,
Error **errp);
Or we could expand it:
DeviceState * qdev_create_isa_serial(int64_t iobase, int64_t irq,
CharDriverState * chardev, Error **errp);
And this is much nicer to use internally.
But, this is bad for libqmp because adding parameters breaks the C API.
The libqmp API really wants to use a structure.
It's not clear to me whether we should have differing internal APIs vs.
libqmp, or whether we should just use structures in QEMU.
Haven't put too much thought into it but that's pretty much a brain dump
of where I am right now.
- why not move command line to qmp instead of new schema?
- single schema
- considerations for -M (didn't capture all of these)
- for all the details:
http://wiki.qemu.org/Features/QCFG
Merging big changes
- in the past, evolving in tree has not worked well, leaving partial
conversions
- QAPI/QCFG method of doing changes in external tree hopes to set new precedent
- put together a detailed specification and make it available for
review very early in the process.
I think this is a critical step too.
- preserve patch/review on list
- do full conversion
- provide strong testing to show it works
Kemari merge plans
- just needs some ACKs
- Juan, Anthony, anybody else who is familiar with migration to review?
switch from gpxe to ipxe
- possible 0.15 release w/ ipxe (Alex looking into it)
- Michael Brown been helpful in fixing bugs, so compat
- Alex will send out mail soon on the details
- ipxe releases? not yet, there are plans for it, should be coming RSN
- Stefan volunteers to help test
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
