Let's add the LKML to this. On 9/13/07, Markus Rechberger <mrechberger@xxxxxxxxx> wrote: > 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 > -- Markus Rechberger _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
