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:41 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 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.