On 02/15/2011 10:26 AM, Chris Wright wrote:
QAPI and QMP
- Anthony adding a new wiki page to describe all of this
http://wiki.qemu.org/Features/QAPI
- specified in formal schema using JSON
- includes documenation in javadoc-like syntax
- can generate api (possibly protocol) docs
- documenting each command and expected errors
- creates marshalling functions and C interfaces
- can generate C library
- facilitates unit tests/regression tests
- new and old code both exist in Anthony's tree
- allows unit tests to run on both to verify
- will remove old and force a flag day on merging in for 0.15
- still need to convert human monitor commands
- goal to convert all of human monitor to QMP
- events?
- still not consumable from internal use
- model signals and slots
- similar to notifier lists, but can pass arbitrary data
- client connects to signal via QMP
- how to extend?
- optional parameters (ABI bump)
- no way to know if client is aware of and consuming the optional
parameters
- add new events
- client required to register for new events when the know about
them, server can generate different logic based on clients
capability
- first release may not include shared library (lack of libconf/autotool)
- could
Just to be clear, this is just not in my current priority list. I'm
much more focused on having full unit tests, documentation, and all HMP
commands converted. If there's time, I will try to do this.
- QMP session in default well-known location
- allows iteration of all running QMP sessions
- per-user directory to handle user-level isolation
qdev future
- have an object model, but can't do polymorphism (i.e. bus level)
- could use more oop style, use GObject, use C++...no great ideas
- no major qdev plans for 0.15
For me, if anyone wants to tackle this, I'd love to have a discussion.
- would be useful to have the ability to do device level unit testing
- cleaner device model, better encapsulation
- this is both the device side interfaces, but also interfaces back to qemu
- ability to do something like a virtual PCI bus to be a test harness
to interact with a device
- back to the GObject, oop, C++ questions?
- IDL based code generation to generate VMState in effort to make
migration more verifiable
- VMState
- need to focus on serialized guest visible state
- start with all state and remove obviously internal only state
- start with only guest visible state (structure separation)
- verfiable
- need a qdev tree maintainer?
- some disagreement on exactly how much
- qdev autodoc patches? (posted and ack'd multiple times)
bad patches committed that are not on list
- please inform of specifics incidents, this should not be happening
SeaBIOS update?
- w/out we will have features that can't be used
- need a release..
- 0.15 will need good planning and dates and communication with Kevin
0.14-rc2 tagged please review for any missing patches, 0.14.0 likely
tagged late today
revisit new -> old migration
- Amit offers virtio-serial patches and some legwork
So, to me, migration correctness trumps compatibility. I don't think
compatibility is useful if it means that a guest may fail during
migration. We have subsections as a way to support the cases where it's
safe to migrate to an old version only if a feature is not being used or
a corner case is not currently happening. This is the best way to
approach the problem.
If a subsection won't work, that means you want to migrate when you're
completely sure that migrating will break a guest. That doesn't seem
reasonable at all to me.
I think in the last discussion on Amit's patches, I had suggested that
subsections could be used to allow migration when there wasn't any
queued data. I think this is the best we can do while preserving
correctness.
Regards,
Anthony Liguori
- tabled discussion to list, possibly next week's call
--
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
