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

Mike Isely isely at isely.net
Wed Aug 22 04:22:04 CEST 2007


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 at pobox.com>

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
                        |                             |



More information about the linux-dvb mailing list