On Monday 27 August 2007 11:01:21 am Steven Toth wrote:
> 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.
I'm a bit late to the party... I concur with Steven and Johannes here, its not
a huge deal exactly where the analog tuning bits land. But between the choice
of Mike's current tree and something with forward declarations, I'd take
Mike's approach. Ultimately, I suppose it'd be nice if they weren't in
dvb_frontend.h, since the d in dvb is digital, but with more and more hybrid
analog/digital cards, it just makes sense to put 'em all in one convenient
place. The less obfuscation the better.
I'm all for the changes too, feel free to add:
Acked-by: Jarod Wilson <jwilson@xxxxxxxxxx>
--
Jarod Wilson
jarod@xxxxxxxxxxxx
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
