Re: [RFC] vtunerc - virtual DVB device driver

[Andreas Oberritter <obi@linuxtv.org>]

On 06/21/2011 03:35 AM, Mauro Carvalho Chehab wrote:
> Em 20-06-2011 18:31, HoP escreveu:
>> 2011/6/20 Mauro Carvalho Chehab <mchehab@redhat.com>:
>>> Em 20-06-2011 17:24, HoP escreveu:
>>>> 2011/6/20 Devin Heitmueller <dheitmueller@kernellabs.com>:
>>>>> On Mon, Jun 20, 2011 at 3:56 PM, HoP <jpetrous@gmail.com> wrote:
>>>>>> Do you think it is really serious enough reason to prevent of having
>>>>>> such virtualization driver in the kernel?
>>>>>>
>>>>>> Let check my situation and tell me how I should continue (TBH, I already
>>>>>> thought that driver can be accepted, but my dumb brain thought because
>>>>>> of non quality code/design or so. It was really big "surprise" which
>>>>>> reason was used aginst it):
>>>>>
>>>>> Yes, this is entirely a political issue and not a technical one.
>>>>
>>>> Political? So we can declare that politics win (again) technicians. Sad.
>>>
>>> This is not a political issue. It is a licensing issue. If you want to use
>>> someone's else code, you need to accept the licensing terms that the developers
>>> are giving you, by either paying the price for the code usage (on closed source
>>> licensing models), or by accepting the license when using an open-sourced code.
>>>
>>> Preserving the open-source eco-system is something that everyone
>>> developing open source expect: basically, you're free to do whatever
>>> you want, but if you're using a code written by an open-source developer,
>>> the expected behaviour that GPL asks (and that the developer wants, when he
>>> opted for GPL) is that you should return back to the community with any
>>> changes you did, including derivative work. This is an essential rule of working
>>> with GPL.
>>>
>>> If you're not happy with that, that's fine. You can implement another stack
>>> that is not GPL-licensed.
>>
>> Mauro, you totally misunderstood me. If you see on my first post in that thread
>> I was sending full GPL-ed driver to the mailinglist.
> 
> You misunderstood me. Something that exposes the kernel interface to for an
> userspace client driver to implement DVB is not a driver, it is a wrapper.
> 
> The real driver will be in userspace, using the DVB stack, and can even be
> closed source. Some developers already tried to do things like that and sell
> the userspace code. Such code submission were nacked. There is even one case
> where the kernelspace code were dropped due to that (and later, replaced by an
> opensource driver).
> 
> We don't want to go on this way again.

Mauro and Devin, I think you're missing the point. This is not about
creating drivers in userspace. This is not about open or closed source.
The "vtuner" interface, as implemented for the Dreambox, is used to
access remote tuners: Put x tuners into y boxes and access them from
another box as if they were local. It's used in conjunction with further
software to receive the transport stream over a network connection.
Honza's code does the same thing.

You don't need it in order to create closed source drivers. You can
already create closed kernel drivers now. Also, you can create tuner
drivers in userspace using the i2c-dev interface. If you like to connect
a userspace driver to a DVB API device node, you can distribute a small
(open or closed) wrapper with it. So what are you arguing about?
Everything you're feared of can already be done since virtually forever.

If you're feared of exposing kernel interfaces to userspace, then I
think your only option is to remove the whole userspace. You might want
to remove i2c-dev and the loadable module interface first.

Regarding the code, Honza, I think the interface is neither clean nor
generic enough to be included in the kernel. It doesn't make much sense
to stay compatible to the interface used by the Dreambox. This interface
evolved from very old versions of the DVB API and therefore carries way
too much cruft and hacks for a shiny new interface. As a side note: Your
ioctl constants already differ from the original vtuner code.

IMO, at least these steps need to be taken:
- Remove unused code. You already mentioned it, but it really should be
removed before submitting code, because it makes review much harder.
- Remove redefined structs and constants.
- Drop support for anything older than S2API.
- Define a way to use an existing demux instead of registering a new
software demux. On hardware that supports it, an input channel should be
allocated for each vtuner, in order to use the hardware's filtering and
decoding capabilities.
- Drop VTUNER_SET_NAME, VTUNER_SET_HAS_OUTPUTS, VTUNER_SET_MODES,
VTUNER_SET_TYPE and VTUNER_SET_NUM_MODES. They are all either specific
to the Dreambox or already obsoleted by S2API commands or should be
implemented as new S2API commands.

Regards,
Andreas