On Sat, 18 Aug 2007, Michael Krufky wrote:
> For the past few months, I've been working on refactoring the analog
> tuner.ko module, such that all hardware-specific code can be separated
> into dvb_frontend style tuner modules.
>
[...]
Acked-by: Mike Isely <isely@xxxxxxxxx>
I've studied the code and it is undeniable that these changes "lower the
entropy" here - long overdue. I've also read through the discussion
thread here so I'll add my $0.02 as well...
Looked at from where I'm sitting the "core" issue has to do with the
intended use of the front end interface. Not being a DVB expert (I've
spent my life here wading through the V4L side), the question has to be:
Is the DVB front end interface supposed to provide a clean abstraction
to operate tuners or is it primarily only ever for the use of the DVB
core?
If it is supposed to be that clean abstraction, then it makes sense to
extend that interface to CLEANLY include the ability to operate things
that perhaps the DVB core is not going to care about - and bolting on a
"hidden" assumed interface through a void pointer (even if that has been
the pattern in the past here) is hardly clean. In fact, if that void
pointer is harboring a pile of function pointers, then the lack of type
checking there is just going to be an open sore for run-time accidents
in the future. Mike's approach to add another method which is by nature
null-initialized and also explicitly null-checked by its caller, is a
nice clean way to extend the API. As I said, if this API's current
purpose (maybe not past purpose) is to correctly abstract operation of a
tuner then it needs to be done cleanly and fairly for all possible uses
of it, including those outside of DVB. What Mike has done fits in with
that approach.
If on the other hand the front end interface is forever to be ruled and
driven only by the needs of the DVB core and nobody is going to accept
extending the interface in ways that perhaps the DVB core isn't going to
use (or otherwise even be bothered about) but others might use, then
perhaps people should be considering a whole separate tuner API,
designed from the ground up with the requirements for operation of all
possible known tuners through it. That would provide the focal point
for merging the two tuner sides together, and not be "biased" towards
DVB or V4L.
Of course the reality is that we want to merge this, right? And it
needs to be done in an efficient manner, with minimal pain. "Minimal
pain" would probably rule a whole new API. So how about we extend the
DVB front end API? And if that can be done without impact to the
existing use of the API - and without creating a type casting minefield,
or additional CPU overhead, then I don't see a downside there. That's
pretty much what Mike has here. Hans' suggestion to move the analog
parameters struct definition out of the way is also fine with me, but I
don't think it's really needed.
-Mike
--
| Mike Isely | PGP fingerprint
Spammers Die!! | | 03 54 43 4D 75 E5 CC 92
| isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8
| |
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
