On 5/19/07, Oliver Endriss <o.endriss@xxxxxx> wrote:
Mauro Carvalho Chehab wrote: > IMO, we should really focus on some code proposition and work on it, until > have most of us happy, not risking break any driver. > > That's said, we should really try to cope together for having a solution. > > >>From my side, I've actively reviewed all Markus patch series. The changes > are not so big, but, since he replaced the usage of the main dvb frontend > struct to a newer one, all drivers needed to be changed. His series looks > ok, but, as touches on all frontends, the internal API should be tested > for all drivers. I did some quick tests with Markus' patchset. Cards which use the stv0299 frontend cause an kernel oops. While it is not hard to fix, it proves that the patchset really breaks some drivers...
Thanks alot for testing and pointing to that problem I added another patchset which should fix that issue.
> The proposed an alternative patch series I've worked were just adding the > newer fields needed from his approach into dvb_frontend struct. > > My suggestion is to you all to take a look on those changes. If the > direction (on Marcus original series or on my series) is ok, we can > improve the corresponding patch series as needed, with contributions from > the developers. > > The API changes(*) on my proposed series are all at: > > http://linuxtv.org/~mchehab/mrec2/hg_mrec_01.patch > > (*) Please ignore the "removal" of xc3028.c from the patch above - The > driver were renamed on Markus tree and moved to another directory. If all > accept this approach, I will move that part to the patch that creates > tuner-xc3028.c. Is this approach ok for the v4l people? Adding new private pointers to struct dvb_frontend is cheap and _cannot_ break any existing driver. For me this is the preferable way to go. (Maybe you should prefix the new fields with the name of the component which will use the pointer, as it was done for tuner_priv, sec_priv etc) What was the reason not to use this approach in the first place?
The reason is that alot work already relies on it and given the fact that earlier discussions lead nowhere it's time to face the sideeffect. As I wrote requests from my side are over now, I'm going on with development again, Markus _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
