Well, I'd like to see Linus' opinion about this, because while programmers keep discussing this, users are waiting forever... so if Markus has a concrete and better solution, why don't use it? And as far as I know, Markus is the programmer who is most interested in this code. I didn't see anybody else in the world doing his work... And I always had a impression that if most of things could be done in user space, than it will be better (for example, devfs -> udev). Why do everything in kernel space? Lets put *less* code in the kernel, not more code. And besides that, code in user space can be changed easily. Code in kernel has to wait a long time for Linus to accept (*if* he accepts). Linus could put an end to this discussion, since he will say the final word. On Thu, 13 Sep 2007 01:10:55 +0200 "Markus Rechberger" <mrechberger@xxxxxxxxx> wrote: > 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 > > > > -- Linux 2.6.22: Holy Dancing Manatees, Batman! http://www.lastfm.pt/user/danielfraga http://u-br.net Dream Theater - "Panic Attack" (Octavarium - 2005) _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
