On 9/12/07, Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> wrote: > Markus, > > Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu: > > Following patch adds the possibility to implement tuner drivers in > > userspace. > > As you asked me about userspace driver, at Linux Conf Europe, let me > give you my feedback about it. > > On Linux, userspace-to-kernelspace APIs are meant to be forever. This > means that, once a newer API is created, this should remain supported > for all future versions. So, such APIs should be carefully analyzed and > accepted by the community, before going to mainstream. > The V4L and DVB API is stable at the moment because it's at a stage which is sufficient for older devices but not sufficient for newer devices anymore. To support newer device it needs a change. > I don't see any technical reason why tuner drivers should be moved to > userspace. Looking at xc3028 device, the driver is very simple and > doesn't require any special treatment that it isn't possible to be done > at kernel. There are already some implementations on kernelspace that > works fine. > As from my side to support the xceive driver properly it needs a rewrite and a proper API description. Since it's not possible to discuss any API changes I will work around at least for those devices which I can support for. > On the other hand, a TV driver without a tuner is a broken driver. With > parts of the driver being at userspace, this means to add undesired > complexity at the drivers architecture, while not bringing any benefit. > > If you look at V4L history, the first drivers started at userspace, > being migrated to kernelspace, where we have the proper scenario for > managing those devices. > > Another aspect that should be analyzed is what is desired by the > community: don't get me wrong but the existing community is rather small and kicking off people who are interested in changing things. I recently had a talk with someone and I've been told that I'm kicking off people. Guess why I kick off people? -> because they do not contribute in a productive way which also means submitting patches. Optical useless changes don't make any difference at the functionality in the end. And my requirements are ignored constantly here. > kernelspace tuners or userspace tuners. Keeping support for > both at long term doesn't seem reasonable. The Linux community should > decide what is the better way. Currently, only you are pushing for > userspace tuners, mainly due to non-technical reasons. read the project site and you will see the reasons. http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages Another advantage is that I have cygwin based code here which I can easily reuse with all that work I'm not going to reinvent the wheel even for newer devices which I work on. > Almost all the > other developers are comfortable with kernelspace tuners. So, creating > an userspace interface just to make you happy is not the way we should > go. > I'm afraid of giving the people which are against what I submitted the responsibility over the project. Initially there was an RFC which didn't get commented either (well there was one useless comment, I tried to discuss it on IRC before with the same guy) after I implemented exactly what I proposed there I got the first non technical comments - also keep in mind that working on something costs alot of time and talking about something unknown is rather cheap. > A final aspect is that having an userspace driver for tuner will mean > that the kernel driver will depend on an userspace counterpart in order > to work. This will allow a vendor with bad intentions to release a > partially broken userspace driver, with limited capabilities, and a > closed source driver for full support. This model is likely to occur, if > you take a look at the past. For example: ATI and Nvidia closed source > drivers, several soft modem drivers, some network drivers, ... > Please go forward and discuss the UIO driver with Greg Kroah Hartmann and the fuse driver with the other people. If companies want to release binary drivers they can easily use the existing code put it into an RPM or DEB package and Ubuntu will pick it up. > With all those issues, I'm against to add an userspace interface for > tuners. > I'm against how the project works out at the moment and how it worked out in history. Exactly this way will kick off companies to be interested in future like Avermedia. A driver can easily be written within a few weeks and I've been struggling with it for 2 years(!!!) now just for nothing finally telling me that some guys want to steal my code and move it to kernelspace although it would raise more complications with upcoming and current devices which have even more requirements. I spent more time in rewriting and discussing everything than to get any of those requirements done. Look at the dvb hotplug patch which came from my side, also look at device node locking where the Hauppauge guy submitted a patch which doesn't work properly because of the spinning thread in the end. I would take my considerations and requirements a bit more serious. Markus _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
