From: Enke Chen <enkechen@cisco.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: linux-media@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
Jonathan Corbet <corbet@lwn.net>,
Andrew Morton <akpm@linux-foundation.org>,
Davide Libenzi <davidel@xmailserver.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
Enke Chen <enkechen@cisco.com>
Subject: Re: [RFCv7 PATCH 0/4] Add poll_requested_events() function.
Date: Thu, 02 Feb 2012 17:58:43 -0800 [thread overview]
Message-ID: <4F2B3F53.7040601@cisco.com> (raw)
In-Reply-To: <1328178417-3876-1-git-send-email-hverkuil@xs4all.nl>
Hi, folks:
I would like to voice my support for Hans' patch.
1) The functionality provided by this patch is needed. I have been
involved in an app that implements a use-land sockets (using FUSE).
Passing the accurate poll events is essential in the app. We have been
using a local patch that is similar (but not identical) for more than a
year. IMO the functionality of passing accurate and consistent events
to a driver is basic, and should be provided by Linux.
2) The patch is safe as far as I can tell. Without the patch, unwanted
events may be passed to a driver. However once the poll returns to the
kernel, the unwanted events would be masked out by the kernel anyway and
would not be passed to an app. Thus a driver that relies on the
unwanted events would not work anyway.
Thanks. -- Enke
On 2/2/12 2:26 AM, Hans Verkuil wrote:
> Hi all,
>
> This is the seventh version of this patch series (the fifth and sixth where
> never posted and where internal iterations only).
>
> Al Viro had concerns about silent API changes. I have made an extensive
> analysis of that in my comments in patch 2/4.
>
> This patch series is rebased to v3.3-rc2. The changes compared to the
> previously posted version are:
>
> - I have renamed the qproc field to pq_proc to prevent any driver that tries
> to access that directly to fail. No kernel driver does this, BTW.
>
> - I added a new poll_does_not_wait() inline that returns true if it is known
> that poll() will not wait on return. This removes the last reason for
> looking inside the poll_table struct. include/net/sock.h has been adapted
> to use this new inline (and it is the only place inside the kernel that
> need this).
>
> I hope that the analysis I made answers any remaining concerns about possible
> silent API changes.
>
> This patch series is also available here:
>
> http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/pollv7
>
> It was suggested to me that creating a new poll system call might be an option
> as well. I've attempted that as well and code implementing that can be found
> here:
>
> http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/pollwithkey
>
> However, I think this turned out to be very messy. And because some drivers
> call the poll fop directly or through some framework I could not be certain I
> was not introducing any errors.
>
> If it is really required to change the API in some way, then I would suggest
> changing this:
>
> typedef struct poll_table_struct {
> poll_queue_proc pq_proc;
> unsigned long key;
> } poll_table;
>
> to this:
>
> struct poll_table {
> poll_queue_proc pq_proc;
> unsigned long key;
> };
>
> and adapting all users.
>
> However, I honestly do not think this is necessary at all. But if it is the
> only way to get this in, then I'll do the work. The media/video subsystem really
> needs this functionality. Also note that previous versions of this patch have
> been in linux-next for months now.
>
> The first version of this patch was posted July 1st, 2011. I really hope that
> it won't take another six months to get a review from a fs developer. As this
> LWN article (http://lwn.net/Articles/450658/) said: 'There has been little
> discussion of the patch; it doesn't seem like there is any real reason for it
> not to go in for 3.1.'
>
> The earliest this can go in now is 3.4. The only reason it takes so long is
> that it has been almost impossible to get a Ack or comments or even just a
> simple reply from the fs developers. That is really frustrating, I'm sorry
> to say.
>
> Anyway, comments, reviews, etc. are very welcome.
>
> Regards,
>
> Hans
>
prev parent reply other threads:[~2012-02-03 1:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-02 10:26 [RFCv7 PATCH 0/4] Add poll_requested_events() function Hans Verkuil
2012-02-02 10:26 ` [RFCv7 PATCH 1/4] eventpoll: set key to the correct events mask Hans Verkuil
2012-02-02 10:26 ` [RFCv7 PATCH 2/4] poll: add poll_requested_events() and poll_does_not_wait() functions Hans Verkuil
2012-02-02 22:48 ` Andrew Morton
2012-02-02 10:26 ` [RFCv7 PATCH 3/4] net/sock.h: use poll_does_not_wait() in sock_poll_wait() Hans Verkuil
2012-02-02 10:26 ` [RFCv7 PATCH 4/4] unix/af_unix.c: use poll_requested_events() in unix_dgram_poll() Hans Verkuil
2012-02-02 22:48 ` [RFCv7 PATCH 0/4] Add poll_requested_events() function Andrew Morton
2012-02-03 9:30 ` Hans Verkuil
2012-02-03 1:58 ` Enke Chen [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=4F2B3F53.7040601@cisco.com \
--to=enkechen@cisco.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=davidel@xmailserver.org \
--cc=hverkuil@xs4all.nl \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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).