On 01/26/2010 02:26 AM, Gerd Hoffmann wrote:
On 01/25/10 23:35, Dor Laor wrote:
On 01/25/2010 04:21 PM, Anthony Liguori wrote:
Another way to look at this is that implementing a somewhat arbitrary
policy within QEMU's .c files is something we should try to avoid.
Implementing arbitrary policy in our default config file is a fine
thing
to do. Default configs are suggested configurations that are modifiable
by a user. Something baked into QEMU is something that ought to work
for
>
If we get the models right, users and mgmt stacks won't need to define
them. It seems like almost impossible task for us, mgmt stack/users
won't do a better job, the opposite I guess. The configs are great, I
have no argument against them, my case is that if we can pin down some
definitions, its better live in the code, like the above models.
It might even help to get the same cpus across the various vendors,
otherwise we might end up with IBM's core2duo, RH's core2duo, Suse's,..
I agree. When looking at this thread and config file idea it feels a
bit like "we have a hard time to agree on some sensible default cpu
types, so lets make this configurable so we don't have to". Which is
a bad thing IMHO.
There's no sensible default. If a user only has Nehalem-EX class
processors and Westmeres, why would they want to limit themselves to
just Nehalem? For an organization that already uses and understand the
VMware grouping, is it wrong for them to want to just use VMware-style
grouping?
This feature is purely data driven. There is no code involved. Any
time a feature is purely data driven and there isn't a clear right and
wrong solution, a configuration file is a natural solution IMHO.
I think the only real question is whether it belongs in the default
config or a dedicated configuration file but honestly that's just a
statement of convention.
Regards,
Anthony Liguori
cheers,
Gerd
--
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
