Manu Abraham wrote: > Edgar Toernig wrote: > >> It should be possible to create a dummy bttv driver that only >> supplies GPIO and I2C access. This dummy driver could even be >> part of the dvb-bt878 driver. (I may be wrong but wasn't the >> first version of the dvb-bt878 driver like that?) But you >> have to find someone who's willing spends some hours of work >> to do that :-) I wouldn't - it's unsatisfying to invest a >> lot of work just to "remove" functionality. >> >> >> > > Yeah, i can understand your feelings. It is kind of very frustraing > when working with a card than spans subsystems, especially when you > have a layered module. I have been subjected to the extreme > frustration a while back, that bttv in V4L used to get screwed up, > resulting in breakages elsewhere. The clueless users will keep > complaining that other modules are not functioning as expected. Well, > this is really hard. > > Well, this is the disadvantage of not having code duplication. > > But the real aspect of it is, that if all modules were to have code > duplication, imagine the sixe of the kernel, and maintainabilty issues. > > The adavantage of not having code duplication is that bugs can be > easily identified out, as the code review does not happen for a > particular hardware, but happens in a generic manner. > > The only way compatibility can be ensured is subsystems play nice to > each other. A while back it was quite difficult to get dvb-kernel and > CVS to play nice to each other. Anyhow that situation has improved a > lot, and it is not as bad as it was earlier. Anyway, both aspects has > their own merits and demerits. > > Manu What about putting the glue code into a pseudo-device module that both the V4L and DVB modules depend on? -Philip
