All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] QEMU configuration files
Date: Wed, 18 Jun 2008 16:08:14 -0500	[thread overview]
Message-ID: <4859793E.1060700@codemonkey.ws> (raw)
In-Reply-To: <48595024.7050400@bellard.org>

Fabrice Bellard wrote:
> Hi,
>
> My snapshot of the "object based" QEMU configuration system can be 
> found at http://bellard.org/qemu/patches . I only tried it for x86 
> targets. It is not yet in committable state and comments are welcome !

I've only done a very quick high level review.  I'll try to do a more 
thorough one soon.  My first impressions are very positive.  I think it 
would be better to decentralize class registration but I don't think 
that's a very hard change to make.

> General ideas:
>
> - User preferences and machine definitions are separated. User 
> preferences are in ~/.qemu/config for Unix systems. Machine 
> definitions can override user preferences but I believe it should be 
> the exception.

Ack.  I think this is pretty important.

> - Command line options override the user preferences and machine 
> definitions.
>
> - Machine definitions contain machine parameters and device 
> definitions. Device definitions are used to create new devices not 
> instanciated in the hardcoded machine definition such as PCI and USB 
> devices.
>
> There are many details which need clarification, in particular:
>
> - PCI, IDE, SCSI and buses naming. It is important if we want to be 
> able to dynamically instantiate complicated bus topologies.
> - USB port naming
> - Is it worth specifying board specific network controllers as 
> separate devices (I tried to do that for smc91c111 devices) ? A 
> simpler solution would be to add new machine parameters to do that.
> - It would be logical to define QEMUDevice for every instanciated 
> device and that register_savevm() use QEMUDevice as parameter, but it 
> requires more changes in the code.

Indeed.  QEMUDevice is a good abstraction as it can be also be used to 
introduce per-device locking which will help parallelize things with KVM.

Regards,

Anthony Liguori

> - Is it worth handling class defaults parameters ? I find the current 
> implementation too complicated.
>
> Fabrice.
>
>
>

  parent reply	other threads:[~2008-06-18 21:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-18 18:12 [Qemu-devel] QEMU configuration files Fabrice Bellard
2008-06-18 19:16 ` [Qemu-devel] " Sebastian Herbszt
2008-06-18 21:08 ` Anthony Liguori [this message]
2008-06-18 23:49 ` [Qemu-devel] " Paul Brook
2008-06-19  0:01   ` Paul Brook
2008-06-19  9:46   ` Fabrice Bellard
2008-06-19 11:40 ` Daniel P. Berrange
2008-06-19 11:52   ` Fabrice Bellard
2008-06-19 14:36     ` Daniel P. Berrange
2008-06-19 11:56   ` [Qemu-devel] " Sebastian Herbszt
2008-06-20 13:11 ` Fabrice Bellard
2008-06-21  8:43   ` Blue Swirl
2008-06-24 15:50 ` [Qemu-devel] " Ian Jackson
2008-06-24 19:50   ` Jamie Lokier

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=4859793E.1060700@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.