From: "David Härdeman" <david@hardeman.nu>
To: Sean Young <sean@mess.org>
Cc: Timo Kokkonen <timo.t.kokkonen@iki.fi>,
Sakari Ailus <sakari.ailus@iki.fi>,
linux-omap@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [PATCHv3 2/9] ir-rx51: Handle signals properly
Date: Mon, 3 Sep 2012 23:41:55 +0200 [thread overview]
Message-ID: <20120903214155.GA6393@hardeman.nu> (raw)
In-Reply-To: <20120903123653.GA7218@pequod.mess.org>
Hej,
On Mon, Sep 03, 2012 at 01:36:53PM +0100, Sean Young wrote:
>On Sun, Sep 02, 2012 at 11:08:20PM +0300, Timo Kokkonen wrote:
>> I guess the assumption is to avoid
>> breaking the transmission in the middle in case the process is signaled.
>> And that's why we shouldn't use interruptible waits.
>>
>> However, if we allow simply breaking the transmitting in case the
>> process is signaled any way during the transmission, then the handling
>> would be trivial in the driver. That is, if someone for example kills or
>> stops the lirc daemon process, then the IR code just wouldn't finish ever.
>>
>> Sean, do you have an opinion how this should or is allowed to work?
>
>You want to know when the hardware is done sending the IR. If you return
>EINTR to user space, how would user space know how much IR has been sent,
>if any?
>
>This ABI is not particularily elegant so there are proposals for a better
>interface which would obsolete the lirc interface. David Hardeman has
>worked on this:
>
>http://patchwork.linuxtv.org/patch/11411/
>
Yes, the first step is an asynchronous interface using a kfifo which is
managed/fed using functionality in rc-core and drained by the drivers.
The size of the kfifo() itself is the only limiting factor right now,
but I do think we should eventually add some restrictions on the combined
duration of the pulse/space timings that are in the queue at any given
point.
Say, for example, that any given pulse/space value is not allowed to be
above 500ms and the total duration of the queue is not allowed to be
above 1000ms. In case user-space wants (for whatever reason)...to write
a 4000ms space, it would have to do so in 8 messages of 500ms each.
Each message write() provides the opportunity for a interruptible wait
(in the regular case) or returning EAGAIN (in the O_NONBLOCK case) -
assuming that the kfifo already holds pulse/space timing totalling
1000ms and/or is full.
EINTR should only be returned if nothing has been written to the kfifo
at all.
That way we would avoid policy in kernel while still making it possible
to kill a misbehaving user-space process by forcing it to drip feed long
TX sequences.
--
David Härdeman
next prev parent reply other threads:[~2012-09-03 21:42 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-30 17:54 [PATCHv3 0/9] Fixes in response to review comments Timo Kokkonen
2012-08-30 17:54 ` [PATCHv3 1/9] ir-rx51: Adjust dependencies Timo Kokkonen
2012-08-30 17:54 ` [PATCHv3 2/9] ir-rx51: Handle signals properly Timo Kokkonen
2012-09-01 17:14 ` Sakari Ailus
2012-09-02 14:54 ` Timo Kokkonen
2012-09-02 15:06 ` Sakari Ailus
2012-09-02 15:20 ` Timo Kokkonen
2012-09-02 19:41 ` Sakari Ailus
2012-09-02 20:08 ` Timo Kokkonen
2012-09-03 12:36 ` Sean Young
2012-09-03 21:41 ` David Härdeman [this message]
2012-09-04 12:43 ` Sean Young
2012-09-20 9:43 ` David Härdeman
2012-09-14 7:58 ` Timo Kokkonen
2012-09-16 19:42 ` Sean Young
2012-08-30 17:54 ` [PATCHv3 3/9] ir-rx51: Trivial fixes Timo Kokkonen
2012-08-30 17:54 ` [PATCHv3 4/9] ir-rx51: Clean up timer initialization code Timo Kokkonen
2012-08-30 17:54 ` [PATCHv3 5/9] ir-rx51: Move platform data checking into probe function Timo Kokkonen
2012-08-30 17:54 ` [PATCHv3 6/9] ir-rx51: Replace module_{init,exit} macros with module_platform_driver Timo Kokkonen
2012-08-30 17:54 ` [PATCHv3 7/9] ir-rx51: Convert latency constraints to PM QoS API Timo Kokkonen
2012-08-30 17:54 ` [PATCHv3 8/9] ir-rx51: Remove useless variable from struct lirc_rx51 Timo Kokkonen
2012-08-30 17:54 ` [PATCHv3 9/9] ir-rx51: Add missing quote mark in Kconfig text Timo Kokkonen
2012-09-01 17:16 ` Sakari Ailus
2012-09-02 14:57 ` Timo Kokkonen
2012-09-02 20:06 ` Sakari Ailus
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=20120903214155.GA6393@hardeman.nu \
--to=david@hardeman.nu \
--cc=linux-media@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=sakari.ailus@iki.fi \
--cc=sean@mess.org \
--cc=timo.t.kokkonen@iki.fi \
/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).