Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driverbecause of worrying about possible misusage?

[HoP]

2011/12/1 Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>:
> On 01-12-2011 12:58, HoP wrote:
>>
>> Hi,
>>
>> let me ask you some details of your interesting idea (how to
>> achieve the same functionality as with vtunerc driver):
>>
>> [...]
>>
>>> The driver, as proposed, is not really a driver, as it doesn't support
>>> any
>>> hardware. The kernel driver would be used to just copy data from one
>>> userspace
>>
>> Please stop learning me what can be called driver and what nope.
>> Your definition is nonsense and I don't want to follow you on it.
>>
>>> application to the other. The same result could be obtained in userspace,
>>> by implementing a library. Such library could even use LD_PRELOAD to
>>> support
>>> binary only applications, like what libv4l does. In terms of performance,
>>> such library would probably perform better than a kernel driver, as
>>> there's
>>> no need to do context switching for each call, and no need to talk with a
>>> device (where kernel outperforms userspace). Also, depending on how such
>>> library
>>> is implemented, double buffering might be avoided.
>>>
>>> So, from architectural POV, this code should be written as an userspace
>>> library.
>>> BTW, alsa also came with the same results, years ago, as audio remote
>>> streaming is supported via userspace tools, like pulseaudio.
>>
>> Can you show me, how then can be reused most important part
>> of dvb-core subsystem like tuning and demuxing?
>
> Why do you need to implement it? Just forward the requests to the machine
> with the real driver.
>
>> Or do you want me
>> to invent wheels and to recode everything in the library?
>
> 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? Two maintaners? That is crazy idea man.

>
>> Of course
>> I can be wrong, I'm no big kernel hacker. So please show me the
>> way for it. BTW, even if you can find the way, then data copying
>> from userspace to the kernel and back is also necessery.
>
> See libv4l, at v4l2-utils.git (at linuxtv.org).
>
>> I really
>> don't see any advantage of you solution.
>
> 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.

Creating additional code which not only enlarge code size by 2
but I think by 10 is really not good idea.  And it get no advantage
only disadvantages.

>
> Don't get me wrong but if you want to submit a code to be merged
> on any existing software (being open source or not), you should be
> prepared to defend your code and justify the need for it to the
> other developers.

Sure. I was prepared for technical disscussion, but was fully suprised
that it was not happend (ok, to be correct, few guys are exception, like
Andreas and few others. I really appreciate it).

So, my question was still not answered: "Can be driver NACKed only
because of worrying about possible misuse?"

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