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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJbz7-2EVgwPY0wkqPVCoOyH2gM_7pf0DzP-Lf4Y65uZpci9GQ@mail.gmail.com>
Date:	Fri, 2 Dec 2011 12:57:58 +0100
From:	HoP <jpetrous@...il.com>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Andreas Oberritter <obi@...uxtv.org>, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver
 because of worrying about possible misusage?

[...]

>>> you failed to convince
>>> people
>>> why this can't be implemented on userspace,
>>
>> Wrong. You failed to convince people why this must be implemented in
>> userspace. Even Michael Krufky, who's "only" against merging it, likes
>> the idea, because it's useful.
>
> Sometimes, when I'm debugging a driver, I use to add several hacks inside
> the kernelspace, in order to do things that are useful on my development
> (debug printk's, dirty hacks, etc). I even have my own set of patches that
> I apply on kvm, in order to sniff PCI traffic. This doesn't mean that
> I should send all those crap upstream.

If you want to disscuss, please better use wordings. Even my Subject was
not about endless discussion that your userspace aproach is better
(me, Andreas and few others doesn't agree with you, it is your own POV,
nobody follows you, if you not noted) don't be so offensive regarding my code.
I don't thing it is so crap.

>
>> Just because something can be implemented in userspace doesn't mean that
>> it's technically superior.
>
> True, but I didn't see anything at the submitted code or at the discussions
> showing that implementing it in kernelspace is technically superior.
>
> What I'm seeing is what is coded there:
>
>        http://code.google.com/p/vtuner/
>
> The kernelspace part is just a piggyback driver, that just copies data
> from/to
> the dvb calls into another device, that sends the request back to userspace.
>
> A separate userspace daemon will get such results and send to the network
> stack:
>
>  http://code.google.com/p/vtuner/source/browse/vtuner-network.c?repo=apps
>
> This is technically inferior of letting the application just talk to vtuner
> directly via some library call.
>
> Btw, applications like vdr, vlc, kaffeine and others already implement their
> own ways to remotelly access the DVB devices without requiring any
> kernelspace piggyback driver.

This in not only about well-known "fatty" applications like vdr, kaffeine etc.
Using vtunerc allows to use any dvb api compatible tools. Like tools
from dvb-tools package (szap/dvbsnoop/...)

There is no more general way of having dvb adapter virtualized.

>
>>> the driver adds hooks at
>>> kernelspace
>>> that would open internal API's that several developers don't agree on
>>> exposing
>>> at userspace, as would allow non GPL license compatible drivers to re-use
>>> their work in a way they are against.
>>
>> What's left is your unreasonable GPL blah blah. So the answer to Honza's
>> question is: Yes, Mauro is nacking the driver because he's worrying
>> about possible misuse.

Well, yes. I feel the same what wrote Andreas. The only pity is that
nobody from outside linuxm-media need to comment that.

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