qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt


From: Anthony Liguori
Subject: Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt
Date: Sun, 25 Mar 2012 08:09:37 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0

On 03/25/2012 05:19 AM, Gleb Natapov wrote:
On Thu, Mar 22, 2012 at 12:50:18PM -0300, Eduardo Habkost wrote:
On Thu, Mar 22, 2012 at 04:30:55PM +0200, Gleb Natapov wrote:
On Thu, Mar 22, 2012 at 10:31:21AM -0300, Eduardo Habkost wrote:
On Thu, Mar 22, 2012 at 11:32:44AM +0200, Gleb Natapov wrote:
What does this mean? Will -nodefconfig disable loading of bios.bin,
option roms, keymaps?

Correcting myself: loading of _config_ files on /usr/share. ROM images
are opaque data to be presented to the guest somehow, just like a disk
image or kernel binary. But maybe keymaps will become "configuration"
someday, I really don't know.

Where do you draw the line between "opaque data" and configuration. CPU
models are also something that is present to a guest somehow.

Just the fact that it's in a structured key=value format that Qemu
itself will interpret before exposing something to the guest. Yes, it's
a bit arbitrary. If we could make everything "configuration data", we
would (or that's what I think Anthony is pushing for--I hope he will
reply and clarify that).

It is not a "bit arbitrary" it is completely arbitrary.

It's the Unix Philosophy:

"Rule of Representation: Fold knowledge into data so program logic can be stupid and robust."

If it can be reasonably represented as data, it should be. If that data can be pushed to a flat text file, it should be. If you can avoid making that special, you should. This keeps your core logic simpler, empowers the user, and creates greater flexibility long term.

Your whole argument seems to boil down to: I don't like this--but you aren't providing any concrete problems. It doesn't make it harder to write a management tool, it's completely invisible to a user, and we have total control over the data files if they're stored in /usr/share.

So what's your concrete concern here? Random comments about kvm tool or Gnome 3 are not concrete concerns. What use-case do you think is impacted here and why (and please be specific)?

http://en.wikipedia.org/wiki/Unix_philosophy

Regards,

Anthony Liguori



reply via email to

[Prev in Thread] Current Thread [Next in Thread]