Michael Hunold wrote:
Hi, On 21.09.2004 15:00, Holger Waechtler wrote:Michael Hunold wrote:I didn't want to waste a lot of time separating the stuff, so the easiest way was to export the ID for now.
Of course dvb_stv0299 should look more like this:
[...]
I still can't see the point of your argumentation, what exactly is the advantage over the trivial implementation proposals Andrew posted?
Andrews struct bus_i2c with the read and write functions is just the same as i2c_transfer(). The current frontends are i2c devices, period. So using your words it's bloat and unnecessary because the code is already there. (That the existing code is stupid in your eyes is another question).
?!?
As I already explained in another mail, introducing a functional dependency between the frontend drivers and the dvb adapters is a no-no. The dvb-ttpci driver would pull in nearly all existing frontend drivers with no benefit.nope. Each special card driver handles exactly one PCI chipset/frontend combination without and if(card_type==XXX) and switch/case statements. Please read the proposed code and the surrounding mails.
If I remember correctly they all followed the easy rule: keep it simple, simplify existing code and throw away bloated code. Break API boundaries where they don't make sense and introduce new ones where they stabilize your system. Seperate the one-code-for-all-module into smaller ones that each suit a particular well-defined and easily testable task.maybe you may also take a look into other software architecture books, Kent Beck's "Extreme Programming" is a nice lecture covering these topics. Don't remember the exact title, it's some years ago that I read it. You'll probably also find a lot of texts on the web.
Been there, done that. You probably know Martin Fowler: Refactoring. Improving the Design of Existing Code, Addison-Wesley Professional 1999, ISBN 0201485672, where the ideas are presented in cooking recipes.