public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Oberritter <obi@linuxtv.org>
To: "Rémi Denis-Courmont" <remi@remlab.net>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Date: Fri, 02 Dec 2011 19:16:40 +0100	[thread overview]
Message-ID: <4ED91608.5020503@linuxtv.org> (raw)
In-Reply-To: <201112021949.19395.remi@remlab.net>

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.

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

  reply	other threads:[~2011-12-02 18:16 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-30 21:38 [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage? HoP
2011-11-30 21:52 ` Michael Krufky
2011-12-01  0:09 ` Andreas Oberritter
2011-12-01 11:04   ` Mauro Carvalho Chehab
2011-12-01 14:58     ` HoP
2011-12-01 17:38       ` Mauro Carvalho Chehab
2011-12-01 19:59         ` HoP
2011-12-01 20:38           ` Mauro Carvalho Chehab
2011-12-01 22:55             ` Andreas Oberritter
2011-12-02 11:14               ` Mauro Carvalho Chehab
2011-12-02 11:48                 ` Andreas Oberritter
2011-12-02 11:57                 ` HoP
2011-12-02 17:33                   ` Mauro Carvalho Chehab
2011-12-02 17:49           ` Rémi Denis-Courmont
2011-12-02 18:16             ` Andreas Oberritter [this message]
2011-12-02 18:28               ` Andreas Oberritter
2011-12-02 23:19       ` Alan Cox
2011-12-03  0:37         ` HoP
2011-12-05 10:21           ` Florian Fainelli
2011-12-05 14:28             ` HoP
2011-12-05 15:16               ` Alan Cox
2011-12-05 15:18               ` Michael Krufky
2011-12-06  0:16                 ` HoP
2011-12-05 17:39               ` Mauro Carvalho Chehab
2011-12-05 20:41                 ` Andreas Oberritter
2011-12-05 20:55                   ` Alan Cox
2011-12-05 21:20                     ` Andreas Oberritter
2011-12-05 21:54                       ` Alan Cox
2011-12-06 11:18                       ` Mark Brown
2011-12-06 12:01                         ` Andreas Oberritter
2011-12-06 13:10                           ` Mauro Carvalho Chehab
2011-12-06 13:35                             ` Andreas Oberritter
2011-12-06 14:13                               ` Mauro Carvalho Chehab
2011-12-06 14:38                                 ` Andreas Oberritter
2011-12-06 15:06                                   ` Mauro Carvalho Chehab
2011-12-06 15:36                                     ` Manu Abraham
2011-12-06 11:21                   ` Mark Brown
2011-12-06 12:01                     ` Andreas Oberritter
2011-12-06 14:19                       ` Mark Brown
2011-12-06 14:48                         ` Andreas Oberritter
2011-12-07 13:49                           ` Mark Brown
2011-12-07 14:01                             ` Andreas Oberritter
2011-12-07 16:10                               ` Mark Brown
2011-12-07 16:56                                 ` Andreas Oberritter
2011-12-07 16:58                                 ` Andreas Oberritter
2011-12-07 21:48                               ` Patrick Dickey
2011-12-07 22:53                                 ` Honza Petrouš
2011-12-07 23:24                                   ` Peter Kolta
2011-12-07 23:55                                 ` Andreas Oberritter
2011-12-11 18:45                               ` Peter martin
2011-12-12 10:31                                 ` Alan Cox
2011-12-06 17:19                         ` Manu Abraham
2011-12-06  0:07                 ` HoP
2011-12-06 13:22                   ` Mauro Carvalho Chehab
2011-12-06 13:49                     ` Andreas Oberritter
2011-12-06 14:19                       ` Rémi Denis-Courmont
2011-12-06 15:05                         ` Andreas Oberritter
2011-12-06 14:20                       ` Mauro Carvalho Chehab
2011-12-06 15:00                         ` Andreas Oberritter
2011-12-06 17:35                           ` HoP
2011-12-03 16:13         ` Andreas Oberritter
2011-12-03 16:42           ` Alan Cox
2011-12-03 17:38             ` Andreas Oberritter
2011-12-03 17:21           ` VDR User
2011-12-03 17:42             ` Alan Cox
2011-12-03 17:48               ` Devin Heitmueller
2011-12-04 23:54                 ` HoP
2011-12-03 18:13               ` Hans Petter Selasky
2011-12-05  0:05                 ` HoP
2011-12-03 18:17               ` Andreas Oberritter
2011-12-03 23:30             ` Walter Van Eetvelt
2011-12-04  0:14               ` VDR User
2011-12-04 14:44                 ` Alan Cox
2011-12-04 23:22             ` HoP
2011-12-05  1:45               ` VDR User
2011-12-05  6:20                 ` HoP
2011-12-02 18:32 ` VDR User

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ED91608.5020503@linuxtv.org \
    --to=obi@linuxtv.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=remi@remlab.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox