[Top][All Lists]

[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: Kevin Wolf
Subject: Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
Date: Tue, 7 Jan 2020 13:29:24 +0100
User-agent: Mutt/1.12.1 (2019-06-15)

Am 07.01.2020 um 13:18 hat Thomas Huth geschrieben:
> 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?

But in those cases where a later option takes priority, at least those
that I'm thinking of right now, it actually completely overrides the
first option as if it hadn't been given.

This one seems to be different in that a later option actually just adds
to the list. Processing a list backwards isn't necessarily less
confusing than what we have.


reply via email to

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