From: Henrik Rydberg <rydberg@euromail.se>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Jiri Kosina <jkosina@suse.cz>,
Mika Kuoppala <mika.kuoppala@nokia.com>,
Benjamin Tissoires <tissoire@cena.fr>,
Rafi Rubin <rafi@seas.upenn.edu>
Subject: Re: [PATCH] input: evdev: Use multi-reader buffer to save space (rev5)
Date: Fri, 25 Jun 2010 15:19:30 +0200 [thread overview]
Message-ID: <4C24ACE2.5000307@euromail.se> (raw)
In-Reply-To: <20100625081445.GA8546@core.coreip.homeip.net>
Dmitry Torokhov wrote:
> On Wed, Jun 23, 2010 at 10:11:47AM +0200, Henrik Rydberg wrote:
>> Dmitry Torokhov wrote:
>>
>>> Overall I am starting getting concerned about proper isolation between
>>> clients. Right now, if one client stops reading events and another one
>>> issues grab then the first client will only get events that were
>>> accumulated before grab tookm place. With the new shared buffer the
>>> first client may get "grabbed" events if it stop for long enough for
>>> buffer to wrap around.
>> Doing some research, the semantics of ioctl have obviously been discussed
>> before, and I believe this points to another such issue. When grabbing a device,
>> are we guaranteeing that the device no longer sends events to other clients, or
>> are we guaranteeing that other clients can no longer read the device? If the
>> latter, clearing all client buffers in conjunction with a grab would be
>> appropriate, and would solve this issue.
>
>
> Yes, I think it would be acceptable approach.
>
>>> Do we really same that much memory here? We normally do not have that
>>> many users connected to event devices at once...
>> Ok, let's scratch this. Although I think the idea of multi-reader buffers is
>> sound, it is obviously sufficiently incompatible with the current approach to
>> produce distastefully complex patches. I will return with a new set which only
>> fixes the buffer resize problem, and leaves the rest for later.
>>
>
> Right, let's merge this and also MT slots and revisit this issue at some
> later point.
Sounds good. I just resent the main MT patches, adding some more Cc:s, and to
make sure we both have the same version. :-) Regarding the ioctl stuff for MT
slots, I did not send those again, I am not sure what to do with them.
Thanks,
Henrik
prev parent reply other threads:[~2010-06-25 13:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-20 18:48 [PATCH] input: evdev: Use multi-reader buffer to save space (rev5) Henrik Rydberg
2010-06-23 6:19 ` Dmitry Torokhov
2010-06-23 8:11 ` Henrik Rydberg
2010-06-25 8:14 ` Dmitry Torokhov
2010-06-25 13:19 ` Henrik Rydberg [this message]
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=4C24ACE2.5000307@euromail.se \
--to=rydberg@euromail.se \
--cc=dmitry.torokhov@gmail.com \
--cc=jkosina@suse.cz \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.kuoppala@nokia.com \
--cc=rafi@seas.upenn.edu \
--cc=tissoire@cena.fr \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.