From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Cedric Le Goater <clg@fr.ibm.com>,
Sukadev Bhattiprolu <sukadev@us.ibm.com>,
video4linux-list@redhat.com, kraxel@bytesex.org,
haveblue@us.ibm.com, serue@us.ibm.com, Containers@lists.osdl.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kthread: saa7134-tvaudio.c
Date: Wed, 30 Aug 2006 14:36:41 -0300 [thread overview]
Message-ID: <1156959402.3852.82.camel@praia> (raw)
In-Reply-To: <20060830094943.bad0d618.akpm@osdl.org>
Em Qua, 2006-08-30 às 09:49 -0700, Andrew Morton escreveu:
> On Wed, 30 Aug 2006 18:30:27 +0200
> Cedric Le Goater <clg@fr.ibm.com> wrote:
>
> > The thread of this driver allows SIGTERM for some obscure reason. Not sure
> > why, I didn't find anything relying on it.
> >
> > could we just remove the allow_signal() ?
> >
>
> I hope so. However I have a bad feeling that the driver wants to accept
> signals from userspace. Hopefully Mauro & co will be able to clue us in.
The history we have on our development tree goes only until Feb, 2004.
This line were added before it.
I've looked briefly the driver. The same allow_signal is also present on
tvaudio (part of bttv driver). BTTV were written to kernel 2.1, so, this
piece seems to be an inheritance from 2.1 time.
No other V4L drivers have this one, although cx88-tvaudio (written on
2.6 series) have a similar kthread to check if audio status changed.
On cx88-tvaudio, it does:
if (kthread_should_stop())
break;
instead of:
if (dev->thread.shutdown || signal_pending(current))
goto done;
It is likely to work if we remove allow_signal and replacing the
signal_pending() by kthread_should_stop() as above.
The better is to check the real patch on a saa7134 hardware before
submiting to mainstream. You may submit the final patch for us to test
at the proper hardware.
Cheers,
Mauro.
next prev parent reply other threads:[~2006-08-30 17:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-29 21:15 [PATCH] kthread: saa7134-tvaudio.c Sukadev Bhattiprolu
2006-08-29 21:22 ` Dave Hansen
2006-08-29 21:39 ` Andrew Morton
2006-08-29 22:39 ` Eric W. Biederman
2006-08-30 12:39 ` Eric W. Biederman
2006-08-30 14:07 ` Cedric Le Goater
2006-08-30 15:43 ` Eric W. Biederman
2006-08-30 16:18 ` Cedric Le Goater
2006-08-30 16:35 ` [Devel] " Kirill Korotaev
2006-08-30 16:38 ` Kir Kolyshkin
2006-08-30 16:30 ` Cedric Le Goater
2006-08-30 16:49 ` Andrew Morton
2006-08-30 17:36 ` Mauro Carvalho Chehab [this message]
2006-08-31 1:02 ` Sukadev Bhattiprolu
2006-08-31 1:05 ` [PATCH] kthread: tvaudio.c Sukadev Bhattiprolu
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=1156959402.3852.82.camel@praia \
--to=mchehab@infradead.org \
--cc=Containers@lists.osdl.org \
--cc=akpm@osdl.org \
--cc=clg@fr.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=kraxel@bytesex.org \
--cc=linux-kernel@vger.kernel.org \
--cc=serue@us.ibm.com \
--cc=sukadev@us.ibm.com \
--cc=video4linux-list@redhat.com \
/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