On 4/10/07, Manu Abraham <abraham.manu@xxxxxxxxx> wrote:
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)
no this was mainly against someone else who insisted to look at something that will not improve anything. I think you forget that my code wasn't written in 2007 and in early 2006 I already asked if someone has ideas about it. http://v4l.videotechnology.com/irc/v4l/2006/03/02 I did all the work with help of a few others who contacted me privatly and tested the code. From the v4l side only Mauro really gave me some feedback, everyone else had other things to do or in your case didn't want to participate. And surprisingly Mauro also has different ideas about such a framework.. so there are 4 developers with possibly 4 different solutions but only one (and that was the RFC I started on the ML without any participation) got realized for the xc3028 back then, and previous attempts of other people to implement such tuners went another way too (back then the situation was easier because of the 4 byte tuning code). So now you come up with your code, it's fine but late. Also not talking/asking me about feedback while developing such a framework is also ignorant, since I've seen issues which you aren't aware of yet. If someone thinks I'll adapt the code I've worked on for years with other people he'll be wrong.
> 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.
for the reason of general unfriendlyness. As I wrote in the DVB Maintainer thread I don't like that people just write your code is bad, I mean I was ok with the mail calling the approach nonsense back then because this basically showed up that some people who write DVB drivers also disagree and have different ideas.
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.
it could affect less but we want to modularize the v4l tuners anyway.
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.
there's absolutly nothing wrong with it, someone might say that it doesn't look nice but that's all about it. I know what I did there, and I already commented it. It's about converting the parameters to another format temporary.
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.
it's also about modularization, I don't see where it duplicates significant parts of the code. it also works well with xc3028 v4l only drivers or xc3028 dvb only drivers without too much overhead finally. If someone wants to add another hybrid module it's very easy that way, significant easier than your current approach since there's one interface. The code got cut out, changed and now it works with both frameworks. I still have several problems with that framework, and I know you have them too because you have no full featured driver packed into your framework neither has anyone tested it yet. Problems will come up if you have a closer look at the i2c part of that driver. Issues are documented on the em28xx ML. which issues about concurrent access? In case of the xc3028 locking is performed on a device node based level. It's only possible to access the v4l or dvb device at a time. Markus _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
