On 23/11/2017 13:39, Cornelia Huck wrote:
> I'm wondering how many people want to run e.g. x86_64-on-x86_64
> _without_ using an available kvm (and I expect those people to
> explicitly specify tcg).
I disagree. I expect them to be "power users" enough to know that
qemu-system-x86_64 defaults to TCG.
Another possibility is that users come here asking for help, we tell
them to test qemu.git, and they are confused by the lack of a qemu-kvm
binary. Ok, maybe not that likely, but it's a category which we want to
have a smooth experience.
>> And in fact that is the main reason why have never bothered switching
>> the default... only RHEL does it, because it ships the QEMU binary as
>> qemu-kvm rather than qemu-system-xxx plus a wrapper script.
>>
>> Perhaps we could:
>>
>> 1) look for "qemu-{kvm,hvf,hax}" in argv[0] and change the "-accel" default?
>>
>> 2) change "make install" to install one or more of qemu-kvm/hvf/hax
>> based on target architecture and OS.
>>
>> Then distros can do away with the script and Windows/Mac users can learn
>> to use qemu-hvf and qemu-hax.
>
> I'm not sure I like that. For me, qemu-kvm comes with the connotation
> of "there used to be a fork of qemu for kvm usage, and we stuck with
> the name because it is likely scattered through scripts".
In theory I don't like it either (and I hadn't thought about it until
today). In practice, qemu-kvm is not going away from
blogs/scripts/tutorials in a decade, so we might as well embrace it...
especially since it has fewer issues than the alternative and even some
advantages:
1) scripts that hardcode qemu-system-x86_64 expecting to use TCG keep to
work
2) it ensures that qemu-kvm works even for those who compile their own QEMU
3) it keeps behavior consistent across all qemu-system-* binaries
4) it reserves the unwieldy name for the thing that you don't want
(think of "exit" vs "_exit" in the C library)
5) we don't have to think about including hax or hvf in the -accel default
Paolo
