Johannes Stezenbach wrote: > In the discussions one month ago I had the impression that serveral > people agreed on this or at least wanted to help to do the > necessary work to get this merged. > whoever said anything got flamed, literally. http://linuxtv.org/pipermail/v4l-dvb-maintainer/2007-February/003623.html (i remember providing advice on this, private mails, over IRC etc, long time back even before i did a RFC, but it got so twisted the communication, that it was portrayed as though i was sabotaging someone's project. Hence i went silent after couple of people adviced just keep quiet on the same) > All private comments to Markus are fine, but if there's > any interest in getting this stuff merged, you need to show > it publicly. > I did not want to touch or comment on the em28xx/xc3028 after i was told to stay away. In spite of all the flames and flamed private mails, i decided to put things in a standard well defined way, such that newer devices will not be affected the same way. > Any comments on the code are good. Not saying anything is bad. > What i have put as an RFC for fixing such issues https://www.redhat.com/mailman/private/video4linux-list/2007-April/msg00022.html http://marc.info/?l=linux-video&m=117571761928085&w=2 A driver for illustrational purposes, with patches for both subsystems which does neither duplicate things nor make one subsystem dependant on the other, while still being light. It also addresses issues such as concurrent accesses, subsystem A accessing the device while subsystem B has a communication going on and vice versa. https://www.redhat.com/mailman/private/video4linux-list/2007-April/msg00047.html http://marc.info/?l=linux-video&m=117613833119350&w=2 > FWIW, I very briefly looked at > http://mcentral.de/hg/~mrec/v4l-dvb-experimental/file/d1e8753a491b/linux/include/media/v4l_dvb_tuner.h > and I think the V4L_OPS macro is invalid because it yields a pointer > to a variable on the stack which just went out of scope. > This might work by accident, but IMHO gcc is allowed to > reuse the stack space for something else immediately after > the closing brace. Not only that. v4l_dvb_tuner does complete duplication of dvb_frontend.h. With such an approach when an API update is performed, such things will break, causing high maintenance and of course not forgetting the flames again. Issues with concurrent access also persists. > HTH, > Johannes > Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
