On 09/01/2012 07:26 PM, Devin Heitmueller wrote:
On Sat, Sep 1, 2012 at 12:13 PM, Antti Palosaari <crope@xxxxxx> 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/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
