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 --]
next prev parent 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).