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 13:49:00 +0000
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 Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote:
> On 06.12.2011 15:19, Mark Brown wrote:

> > Your assertatation that applications should ignore the underlying
> > transport (which seems to be a big part of what you're saying) isn't
> > entirely in line with reality.

> Did you notice that we're talking about a very particular application?

*sigh*

> VoIP really is totally off-topic. The B in DVB stands for broadcast.
> There's only one direction in which MPEG payload is to be sent (using
> RTP for example). You can't just re-encode the data on the fly without
> loss of information.

This is pretty much exactly the case for VoIP some of the time (though
obviously bidirectional use cases are rather common there's things like
conferencing).  I would really expect similar considerations to apply
for video content as they certainly do in videoconferencing VoIP
applications - if the application knows about the network it can tailor
what it's doing to that network.  

For example, if it is using a network with a guaranteed bandwidth it can
assume that bandwidth.  If it knows something about the structure of the
network it may be able to arrange to work around choke points.
Depending on the situation even something lossy may be the answer - if
it's the difference between working at all and not working then the cost
may be worth it.
--
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/