[linux-dvb] [RFC] Hybrid tuner refactoring, phase 1

Johannes Stezenbach js at linuxtv.org
Tue Aug 21 01:01:25 CEST 2007

On Mon, Aug 20, 2007, Manu Abraham wrote:
> Michael Krufky wrote:
> >  -- this is a system-wide addition to the
> > dvb_frontend structure, because we are adding analog tuning
> > functionality to the dvb_frontend.
> Analog tuning is public to DVB core ? I don't think so. It would've been
> correct, if DVB core does analog operations, but DVB core doesn't do any
> Analog operations.

Well, supporting hybrid tuners means that analog and digital
worlds have to touch somewhere...

> > I agree that elegance is very important, and that is why I disagree with
> > the extra layers of complexity that you are proposing here.
> Every DVB demodulator driver that you write does this.
> struct dvb_frontend {
> 	struct dvb_frontend_ops ops;
> 	struct dvb_adapter *dvb;
> 	void* demodulator_priv;
> 	void* tuner_priv;
> 	void* frontend_priv;
> 	void* sec_priv;
> 	void* hybrid_priv;
> };
> So whatever that which dvb_core doesn't handle is "private". I don't
> understand what you mean by extra complex layer.

I think the rule of thumb is to use void* only when it points
to different things for each driver (e.g. struct tda8083_state*,
struct ves1820_state* etc.). If we know it will always point to
struct analog_parameters (or set_analog_params) then using
void* is IMHO wrong.

Using a forward decl for struct analog_parameters and putting
struct analog_parameters somewhere else like Hans suggested
would be OK, but doesn't seem that important to me. I mean the
whole separation of analog and digital tuning APIs is artificial
and is just a result of how development happend in two distinct
communities historically. Why spent any effort to keep them
completely seperate instead of letting them grow together?

Anyway, I think it's not a fundamental issue and could be
changed at any time without affecting the basic approach
this proposal takes to implement hybrid tuners.


More information about the linux-dvb mailing list