qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM


From: Kevin Wolf
Subject: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM
Date: Fri, 23 Oct 2009 09:40:45 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3

Am 23.10.2009 01:55, schrieb Juan Quintela:
> Anthony Liguori <address@hidden> wrote:
>> Luiz Capitulino wrote:
>>> On Thu, 22 Oct 2009 10:40:54 -0500
>>> Anthony Liguori <address@hidden> wrote:
>>>
>>>   
>>>> Luiz Capitulino wrote:
>>>>     
>>>>>  Yeah, I agree.
>>>>>
>>>>>  When testing migration, for example, I have to type 'migrate -d 
>>>>> tcp:0:4444'
>>>>> several times... Maybe there's a smarter way to do this, but the monitor
>>>>> macros idea seems interesting to me.
>>>>>         
>>>> When we have QMP, we can create a QMP socket at a well known
>>>> location based on the -name parameter.  We could also introduce a
>>>> qm command that allowed one to execute monitor commands from the
>>>> shell.  That allows people to write whatever crazy shell scripts
>>>> they want.
>>>>     
>>>
>>>  Yes.
>>>
>>>  What about the macros idea? Are you against it?
>>>   
>>
>> I'm concerned that it's a snowball of complexity waiting to happen for
>> very little benefit.
>>
>> I think we're trying to solve a non-existent problem.
> 
> I fully agree.  If we have a had to issue commands to the monitor, we
> can use whatever shell/interpreter/... that we like.

But I can't bind a keyboard shortcut to such a script which is exactly
what this thread is about... What I want to have in the end is my "VM
stop" shortcut, dynamically binding keys to monitor commands is just a
way to achieve this.

I really hate this "You don't need this, I know it better" attitude. If
it were only for the technical arguments, okay - I can understand that
you don't want to add another magic key, and yes, doing it dynamically
comes with some complexity. But all this talking about "non-existent
problems" makes me think that you don't... really care about what users
want if they are the wrong users (yes, I admit, this one is useful more
likely for developers and plain qemu users than for those running their
servers in KVM - but they are still users, right?)

Kevin




reply via email to

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