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]

Message-ID: <20111207161058.GC22355@opensource.wolfsonmicro.com>
Date:	Thu, 8 Dec 2011 00:10:59 +0800
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Andreas Oberritter <obi@...uxtv.org>
Cc:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	HoP <jpetrous@...il.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	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?

On Wed, Dec 07, 2011 at 03:01:18PM +0100, Andreas Oberritter wrote:

> Once and for all: We have *not* discussed a generic video streaming
> application. It's only, I repeat, only about accessing a remote DVB API
> tuner *as if it was local*. No data received from a satellite, cable or
> terrestrial DVB network shall be modified by this application!

> Virtually *every* user of it will use it in a LAN.

> It can't be so hard to understand.

You're talking about a purely software defined thing that goes in the
kernel - it pretty much has to be able to scale to other applications
even if some of the implementation is left for later.  Once things like
this get included in the kernel they become part of the ABI and having
multiple specific things ends up being a recipie for confusion as users
have to work out which of the options is most appropriate for their
application.

Really this feels like the pattern we've got with audio where we
restrict the drivers to driving hardware and there's a userspace which
wraps that and can also dispatch to a userspace implementation without
applications worrying about it.  Perhaps given the current entirely in
kernel implementation a simple loopback in the style of FUSE which
bounces the kernel APIs up to userspace for virtual drivers would make
sense.
--
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/