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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 7 Dec 2011 23:24:31 +0000 (UTC)
From:	Peter Kolta <peterkolta63@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

Honza Petrouš <jpetrous <at> gmail.com> writes:

> 
> 2011/12/7 Patrick Dickey <pdickeybeta <at> gmail.com>:
> > On 12/07/2011 08:01 AM, Andreas Oberritter wrote:
> >> On 07.12.2011 14:49, Mark Brown wrote:
> >>> On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote:
> >>>> On 06.12.2011 15:19, Mark Brown wrote:
> >>>
> > I tend to stay out of these discussions, since like a couple of others,
> > I'm not a kernel developer (or hacker). However, I wanted to chime in
> > with my two cents here.
> >
> > 1.  I agree that it's not acceptable to "NACK" purely for philosophical
> > reasons (except when it's a clear violation of a license--be that open
> > source or closed source (since we don't want to open ourselves up to
> > lawsuits).
> >
> > 2.  In this case, there have been technical reasons provided. Granted
> > the developers (and people who are pro-inclusion) don't feel those are
> > justified, but they have been cited.
> >
> > 3.  You'll catch more flies with honey than vinegar (in other words,
> > fighting with the person(s) who maintain the project will most
> > definitely *not* get your code included).
> 
> Yes, that I think we all know. But some problem is that the arguments
> against it are very weak. Believe me I would prefer to work on all
> hints which kernel hackers gave me after code reviewing and not
> to be member of flamewar.
> 

I took the time and went through this thread.
I like the idea of supporting the device via network, but I do not like the idea 
of having a virtual driver and server separate for this.
Before adding this hackish approach you can do a better design at early stages 
right now.

Why can't you just patch the necessary functions of the applications which you 
pointed out to access a library? This would totally eliminate the need of the 
kernel module. It would greatly enhance the usability of this feature.

> Some features are designed for LAN use. I think nobody wants to use
> SMBFS over Internet. But in LAN it works perfectly stable.
> 

SMBFS does not need to deliver data at a constant bitrate, several companies are 
doing that via VPNs.
> 
> As you stated already - maintaining kernel-space code out of kernel
> tree is much difficult. If anybody did any change in internal API, then
> you have to catch it yourself, find the way to change your code
> accordingly. If it would be in kernel, then such job is required to be
> done by patch contributor.
> 

I would not support this attempt, since right now you can do it a better way.
You even named it, streamdev for vdr why don't you improve it?
If you add some transcoding functionality to your idea you can do it all on 
application level and even stream it to the internet.
The virtual device seems to be a dead end for me which makes all those things 
more complicated in the end.

Peter

--
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/