qemu-block
[Top][All Lists]
Advanced

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

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to


From: Thomas Huth
Subject: Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
Date: Tue, 7 Jan 2020 13:18:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 07/01/2020 11.14, Paolo Bonzini wrote:
> On 07/01/20 11:03, Thomas Huth wrote:
>>>  
>>>  vm = QEMUMachine(iotests.qemu_prog)
>>> -vm.add_args('-machine', 'accel=kvm:tcg')
>>> +vm.add_args('-accel', 'kvm', '-accel', 'tcg')
>> Looking at this, I wonder whether we really want the "-accel" option to
>> prioritize the accelerators in the order of appearance? A lot of other
>> CLI tools give the highest priority to the last parameter instead, e.g.
>> "gcc -O3 -O1" compiles with -O1, and not with -O3.
>>
>> Also I think it might be quite common that there are shell scripts which
>> call "qemu-system-xxx -accel xyz $*" ... and if we don't invert the
>> priorities of -accel, it will be impossible to override -accel in that
>> case...
> 
> Hmm, it does match "-machine accel=kvm:tcg" and in general I think it's
> more self-explanatory.  However, it is indeed less friendly to scripts.
>  On one hand those could be changed to place "-accel xyz" after $* (or
> better "$@"), on the other hand we could also add a priority option to
> "-accel".  What do you think?

I don't think we need a separate priority parameter here. But IMHO it's
 really rather common practice to prioritize the last option. So while
it might be more "self-explanatory" to a CLI newbie if the first
occurrence got the highest priority, it might be rather confusing
instead for a CLI veteran...?

What do others on the list here think about this?

 Thomas




reply via email to

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