From: Antti Palosaari <crope@iki.fi>
To: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: poma <pomidorabelisima@gmail.com>,
Mauro Carvalho Chehab <mchehab@redhat.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Juergen Lock <nox@jelal.kn-bremen.de>,
hselasky@c2i.net
Subject: Re: Fwd: [PATCH, RFC] Fix DVB ioctls failing if frontend open/closed too fast
Date: Sat, 01 Sep 2012 19:38:44 +0300 [thread overview]
Message-ID: <50423A14.6090306@iki.fi> (raw)
In-Reply-To: <CAGoCfiy=nbL1MvLZmiRG0JZe+69VBjPNur8R64pcoL0f3Y7Q_A@mail.gmail.com>
On 09/01/2012 07:26 PM, Devin Heitmueller wrote:
> On Sat, Sep 1, 2012 at 12:13 PM, Antti Palosaari <crope@iki.fi> wrote:
>> Is there anyone caring to review that carefully?
>>
>> I am quite out with semaphores (up/down_interruptible) and also frontend is
>> so complex... I would rather design / write whole dvb-frontend from the
>> scratch :] (not doing that as no time).
>
> If you're not willing to take the time to understand why the existing
> dvb-frontend is so complex, how could you possibly suggest that you
> could do a better job rewriting it from scratch? :-)
Writing and designing things from the scratch is more motivated that
trying to learn this much complex stuff. You surely know I has a kinda
understanding with current dvb-frontend but I hate there is so much
hacks which makes it even worse. Writing from the scratch means you
could get rid of hacks - slowly.
See all the module parameters and think twice are those really needed?
Also re-initialization stuff and what more. Unfortunately those are
allowed at some phase as easy solution and now it is impossible to get
rid. Hacks which belongs to individual drivers instead of core.
> Like most things, the devil is in the details. The threading model is
> complicated not because it was done poorly, but because there are lots
> of complexity that is not obvious (combined with it having evolved
> over time to adapt to hardware bugs). It's only when you run it
> against a half dozen cards with different behavior that you begin to
> see why certain things were done the way they were.
>
> In this case, I think the race condition in question has become more
> obvious because of more aggressive use of power management for the
> tuner and demod. Because powering down the frontend now takes actual
> time (due to i2c), users are now starting to hit the race condition.
>
> Devin
>
regards
Antti
--
http://palosaari.fi/
next prev parent reply other threads:[~2012-09-01 16:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-31 22:22 [PATCH, RFC] Fix DVB ioctls failing if frontend open/closed too fast Juergen Lock
2012-08-12 2:15 ` Fwd: " Mauro Carvalho Chehab
2012-08-12 3:06 ` Devin Heitmueller
2012-08-28 20:56 ` Hans Petter Selasky
2012-09-01 15:51 ` Fwd: " poma
2012-09-01 16:13 ` Antti Palosaari
2012-09-01 16:26 ` Devin Heitmueller
2012-09-01 16:38 ` Antti Palosaari [this message]
2012-09-26 20:11 ` [PATCH, RFC, updated] " Juergen Lock
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=50423A14.6090306@iki.fi \
--to=crope@iki.fi \
--cc=dheitmueller@kernellabs.com \
--cc=hselasky@c2i.net \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@redhat.com \
--cc=nox@jelal.kn-bremen.de \
--cc=pomidorabelisima@gmail.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;
as well as URLs for NNTP newsgroup(s).