qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Amos Kong <akong@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: mtosatti@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH] ui/input: strictly check console in finding input handler
Date: Thu, 6 Nov 2014 23:01:11 +0800	[thread overview]
Message-ID: <20141106150111.GA25471@air.redhat.com> (raw)
In-Reply-To: <20141106063754.GF8764@air.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2966 bytes --]

On Thu, Nov 06, 2014 at 02:37:54PM +0800, Amos Kong wrote:
> On Wed, Nov 05, 2014 at 09:47:47AM +0100, Gerd Hoffmann wrote:
> > On Mi, 2014-11-05 at 00:49 +0800, Amos Kong wrote:
> > > qemu_input_find_handler() prefers a handler associated with con.
> > > But if none exists, it takes any. This patch added a parameter
> > > to strictly check console, in case we want to input event to
> > > special console.
> 
> If console is assigned, it will try to find right handler by first
> loop in qemu_input_find_handler(). The second loop is used to find
> mask matched handler if console isn't assigned.
> 
> If we assigned console and didn't find handler in first loop, it
> skip second loop body by 'continue', and return NULL.
> It seems my concern is wrong, we don't need this repeated parameter.

I was wrong, if we don't assign the console for qemu_input_find_handler(),
it has chance to get an arbitrary console (mask matched). So the
original issue this patch try to fix truely exists.
 
> NACK this patch.
> 
> Thanks.
>  
> > > 'input-send-event' has a parameter to assign special console,
> > > so we should enable strict checking in finding handler.
> > 
> > I don't think we want do that by default.  It only matters in case of a
> > multiseat setup where you actually have multiple input devices of the
> > same kind.  Which isn't a very typical use case.
> > 
> > Options I see are:
> > 
> >   (a) Turn console into an optional parameter, do strict checking in
> >       case it is present.
> >   (b) Add a optional 'strict' parameter.
> 
> -- 
> 			Amos.

From Markus:
> 
> Current behavior (please correct misunderstandings):
> 
>     The guest must be running.
>     input-send-event parameter 'console' is mandatory.
>     The console identified by its value must exist.
>     If this console can accept the event, send it there.
>     Else, a console that can accept the event must exist.  Send it
>     to
>     one of them.  Which one exactly isn't specified.
> 
> Behavior with (a):
> 
>     The guest must be running.
>     input-send-event parameter 'console' is optional.
>     If it's present, the console identified by its value must exist,
>     and
>     must be able to accept the event.  Send it there.
>     Else, a console that can accept the event must exist.  Send it
>     to
>     one of them.  Which one exactly isn't specified.
> 
> "Must" means "or else command fails".
> 
> I think that's a clear improvement.  It's actually what I expected
> from
> the command documentation, until I read the code.

Thanks for your clear description, I now agree with Gerd's option (a),
(a) is better than (b). So we need to change QMP to support optional
console parameter and change qemu_input_find_handler() to support
strict checking (as my patch).

Gerd, I'd like to work on both of them, if you already work on it,
please let me know, thanks. 

-- 
			Amos.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-11-06 15:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-04 16:49 [Qemu-devel] [PATCH] ui/input: strictly check console in finding input handler Amos Kong
2014-11-05  8:47 ` Gerd Hoffmann
2014-11-06  6:37   ` Amos Kong
2014-11-06 15:01     ` Amos Kong [this message]
2014-11-07  4:16       ` Amos Kong
2014-11-06  9:00   ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141106150111.GA25471@air.redhat.com \
    --to=akong@redhat.com \
    --cc=armbru@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).