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

Steven Toth stoth at hauppauge.com
Mon Aug 27 17:01:21 CEST 2007


Johannes Stezenbach wrote:
> 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?
>
>   

I'm glad someone else also raised this. The legacy of two different 
video/tv frameworks has been biting for a long time, and will continue 
to do so. Issues like a forward declaration vs anything else feels 
irrelevant and trivial to me, especially when I look at the overall 
problems with having one concept (tv/video) in two distinct frameworks.

We should be striving for a unified tuning API which abstracts all 
frontend types, regardless of the underlying hardware. I know we cannot 
make that leap quickly, it's going to take constant refinement over a 
series of years. That being said, knowing how difficult it can be to get 
things accepted, these patches are a net gain to the project and I have 
no immediate objections.

... I'm still reading, more later.

> 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