qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

             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).