Hi, On 23.09.2004 02:05, Andrew de Quincey wrote:
On Wednesday 22 Sep 2004 23:02, Wolfgang Wegner wrote:On Wed, Sep 22, 2004 at 10:09:14PM +0100, Andrew de Quincey wrote:
demod_driver functionality:
pll_driver functionality:
frontend_driver functionality:
of course, this is just the rough outline to make clear what i was thinking about.
Like this, an additional layer is introduced (what i called "frontend" here), but the demod itself should stay quite clean while still being configurable and re-usable. Or you think this already to be code bloat? The "frontend" layer could then be implemented for each card (thus including knowledge about i2c adapter and i2c address of the devices), to allow simply calling some frontend_create()s for all the frontends expected for this device id until one succeeds. Also, like this, i do not see where a dependency on a special i2c adapter is as long as a wrapper can be provided to have a general API for them. Did i think too complicated about all this?
I think maybe - I have a tendency to do that as well though.I now agree with that. If we see that several adapters have the same pll and/or glue logic, then we can still create some small abstraction to avoid code duplication.
I think everyone agrees that what are currently the "frontend drivers" should from now on only control the demodulators.
If you look back in the list, I proposed having a "pll library", which is very similar to your pll_driver idea. However, as everyone pointed out, most PLLs are only about 20 lines of code - so having an entire driver structure for them is overkill... I agree with this (now :)
In the end, I think we should keep it as simple as possible - having demodulator drivers since they are generally substantial pieces of code, and just making the card drivers implement the PLLs/glue logic themselves is simplest, and leads to the best balance of code bloat vs. code nastiness we can hope for.