From: Chris Wright <chrisw@redhat.com>
To: kvm@vger.kernel.org
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] KVM call minutes for Mar 15
Date: Tue, 15 Mar 2011 07:53:46 -0700 [thread overview]
Message-ID: <20110315145346.GH20456@x200.localdomain> (raw)
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
- 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
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
- 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
- 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
next reply other threads:[~2011-03-15 14:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-15 14:53 Chris Wright [this message]
2011-03-15 16:28 ` [Qemu-devel] KVM call minutes for Mar 15 Anthony Liguori
2011-03-15 19:06 ` Chris Wright
2011-03-15 21:05 ` Anthony Liguori
2011-03-17 10:34 ` [libvirt] " Daniel P. Berrange
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110315145346.GH20456@x200.localdomain \
--to=chrisw@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).