lkml.org 
[lkml]   [2011]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 02.12.2011 19:16, Andreas Oberritter wrote:
> On 02.12.2011 18:49, Rémi Denis-Courmont wrote:
>> Le jeudi 1 décembre 2011 21:59:56 HoP, vous avez écrit :
>>>> Kernel code is GPLv2. You can use its code on a GPLv2 licensed library.
>>>
>>> I see. So if you think it is nice to get dvb-core, make a wrapper around
>>> to get it usable in userspace and maintain totally same functionality
>>> by myself then I say it is no go. If it looks for you like good idea
>>> I must disagree. Code duplication?
>>
>> Sure, some core code would be duplicated. That is not a big deal.
>>
>> This proposal however has three big advantages:
>> - Proprietary drivers are not enabled as the library would be GPL.
>> - The virtual DVB device runs in the same process as the DVB application,
>> which saves context switching and memory copying.
>> - It would be your project. You do not need to agree with Mauro ;-)
>>
>>> Two maintaners? That is crazy idea man.
>>
>> Someone would have to maintain the device driver anyway. I don't see much of a
>> difference on maintainance side.
>>
>>>> And I can't see any advantage on yours ;) Putting something that belongs
>>>> to userspace into kernelspace just because it is easier to re-use the
>>>> existing code inside the kernel is not a good argument.
>>>
>>> It is only your POV that it should be in userspace.Also, LGPL drivers
>>
>> Except for backward compatiblity, this would actually belong in userspace. It
>> would be more efficient and easier to maintain as a userspace library than as
>> a kernel driver.
>
> Maintaining the kernel module would be rather easy, because new
> properties added to dvb_frontend would be handled transparently. The
> implementation is quite simple. In contrast, implementing and then
> maintaining all the users of a newly written userspace library would be
> a nightmare in comparison.
>
>> If you need backward compatibility, I am still inclined to believe that you
>> could write a CUSE frontend, so it does involve some extra work and looses the
>> performance benefit.

One more note: CUSE would conflict with dvb-core the same way Mauro's
sockets would do.

> How would all this allow to use e.g. dvbsnoop or w_scan on a remote
> tuner? Do you propose to add a dependency to this proposed library to
> every application?
>
> Furthermore, a GPLv2 library would artificially restrict its users, e.g.
> you wouldn't be allowed to use it with gstreamer or just with anything
> that isn't GPLv2, not even v3.
>
> Regards,
> Andreas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2011-12-02 19:31    [W:0.228 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site