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. > > _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb