Em 22-06-2011 11:24, Andreas Oberritter escreveu: > On 06/22/2011 03:45 PM, Mauro Carvalho Chehab wrote: >> Em 22-06-2011 10:13, Andreas Oberritter escreveu: >>> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: >>>> Em 22-06-2011 09:37, HoP escreveu: >>>>> 2011/6/22 Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>: >>>>>> Em 21-06-2011 14:38, HoP escreveu: >>>>>>> 2011/6/21 Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>: > [...] >>>>>>>> If people have different understandings, then we'll likely need to ask some >>>>>>>> support from Open source lawyers about this subject. >>>>>>> >>>>>>> My very little opinion is that waving GPL is way to the hell. Nobody told me >>>>>>> why similar technologies, in different kernel parts are acceptable, >>>>>>> but not here. >>>>>> >>>>>> If you want to do the networking code at userspace, why do you need a kernel >>>>>> driver after all? The proper solution is to write an userspace library for that, >>>>>> and either enclose such library inside the applications, or use LD_PRELOAD to >>>>>> bind the library to handle the open/close/ioctl glibc calls. libv4l does that. >>>>>> As it proofed to be a good library, now almost all V4L applications are using >>>>>> it. >>>>> >>>>> LD_PELOAD is out of bussiness for normal work. It is technique for development >>>>> and/or debugging. >>>> >>>> Well, libv4l successfully uses LD_PRELOAD in order to support all applications >>>> that weren't ported to it yet. It offers two ways: >>>> 1) you can use it as a normal library; >>>> 2) you can use it with LD_PRELOAD. >>>> >>>> >>>>> Library would be possible, but then you kill main advantage >>>>> - totally independece of changes inside userland DVB applications. >>>> >>>> Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same syntax of >>>> glibc open, ioctl, ..., the efforts to migrate an userspace application to use it >>>> is to just run: >>>> sed s,open,dvb_open,g >>>> sed s,ioctl,dvb_ioctl,g >>>> >>>> >>>> The library and the application will be completely independent. >>> >>> How do you transparently set up the network parameters? By using >>> environment variables? How do you pass existing sockets to the library? >>> How do you intercept an open() that won't ever happen, because no >>> virtual device to be opened exists? >> >> Sorry, but I failed to see at the vtunerc driver anything network-related. > > Of course it doesn't. You're the one who proposed to put networking into > the driver. I however fail to see how you imagined to add remote tuner > support to any existing application by using LD_PRELOAD. If you take a look at libv4l, it hooks calls to open/close/ioctl/read/write glibc calls. So, when an userspace application calls "open", it will run the library code, and not glibc open function. So, it is completely transparent to the userspace application. >> Also, the picture shows that it is just acting as a proxy to an userspace code >> that it is actually handling the network conversion. The complete solution >> seems to have a kernel driver and an userspace client/daemon. > > Right. > >> Technically, doing such proxy in kernel is not a good idea, due to several >> reasons: >> >> 1) The proxy code and the userspace network client will need to be tightly coupled: >> if you add a new feature at the proxy, the same feature will need to be supported by >> the userspace daemon; > > Just like anything else DVB related inside the kernel. Yes. > Adding a new feature to the proxy would mean that a new feature got > added to the frontend API, so a new kernel would be required anyway. > >> 2) Data will need to be using copy_from_user/copy_to_user for every data access; > > Also, just like anything else DVB related inside the kernel. Yes, but if you do it on userspace, you don't need to do double buffering. With a proxy, the same data will need to be passed 3 times from/to kernelspace: 2 times at vtunerc, and 1 time to the network driver. If implemented on userspace, all it needed is to pass the data to the network driver, reducing latency. Also, newer functions can be added on userspace in order to optimize applications that will use it as a library, like providing functions that combine DVB and network commands altogether. > No one would notice some frontend ioctl parameters being copied twice. > We're talking about a few bytes. If the intention is to limit it to just frontend ioctl's, you're right: the only difference is that latency will be a little higher, probably unnoticed (yet, introduced for not a good reason). But, if the intention is to also provide remote streaming, then the volume of data copied tree times will be noticeable, especially if the stream is in HD and/or if support for full-featured DVB cards is added later. > Passing the remote TS to the kernel is completely *optional*, and only > required if you want to use the kernel's demux or the underlying > hardware's filtering and decoding features. However, the TS even gets > filtered before being transferred over the network. So again, even if > used though being optional, this is not a big data rate. > >> 3) There's no good reason to write such code inside kernelspace. >> >> On a library based approach, what you'll have, instead is a library. The same >> userspace client/daemon will be needed. However, as both can be shipped together >> (the library proxy code and the userspace client/daemon), there are several >> advantages, like: >> >> 1) The library and the userspace client will be in sync: there's no need to check >> for version differences at the api, or providing any sort of backport support; > > Breaking the ABI of libraries isn't much better than breaking the ABI of > kernel interfaces. A library may have many users, more than "the > userspace client" you're talking about. That's partially true. If the library and the userspace client are bound together, if new features are added at the library, the userspace client can assume that those new features will be there. So, you only need to take care with backward compatibility at the library side. With that functionality in Kernel, backward compatibility should be warranted on both ways. >> 2) There's no need to recompile the kernel when someone wants to use the proxy; > > You could of course build it as a module, without the need to recompile > the kernel. Yes. >> 3) The userspace won't be bound to the Kernel release schedule: When the code is >> stable enough, both libraries and userspace can be released at the same time. > > For the same reason one could argue that putting device drivers into > userspace would have the same benefits. > > Well, the original proposal was to add a driver with supporting programs > which enables every existing DVB application to *transparently* work > with remote tuners. > > What you're proposing now is to write a library, which works with remote > tuners, too, but which requires manual integration into each and every > application. With LD_PRELOAD, it will be transparent. > By the way, if we had such a library, supported by every major > application, then it would be very easy to implement closed source > frontend drivers on top of it. ;-) True. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
