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:	Sat, 3 Dec 2011 17:42:47 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	VDR User <user.vdr@...il.com>
Cc:	Andreas Oberritter <obi@...uxtv.org>, HoP <jpetrous@...il.com>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	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 Sat, 3 Dec 2011 09:21:23 -0800
VDR User <user.vdr@...il.com> wrote:

> On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter <obi@...uxtv.org> wrote:
> > You could certainly build a library to reach a different goal. The goal
> > of vtuner is to access remote tuners with any existing program
> > implementing the DVB API.
> 
> So you could finally use VDR as a server/client setup using vtuner,
> right? With full OSD, timer, etc? Yes, I'm aware that streamdev
> exists. It was horrible when I tried it last (a long time ago) and I
> understand it's gotten better. But it's not a suitable replacement for
> a real server/client setup. It sounds like using vtuner, this would
> finally be possible and since Klaus has no intention of ever
> modernizing VDR into server/client (that I'm aware of), it's also the
> only suitable option as well.

I would expect it to still suck. One of the problems you have with trying
to pretend things are not networked is that you fake asynchronous events
synchronously, you can't properly cover error cases and as a result you
get things like ioctls that hang for two minutes or fail in bogus and
bizarre ways. If you loop via userspace you've also got to deal with
deadlocks and all sorts of horrible cornercases like the user space
daemon dying.

There is a reason properly working client/server code looks different -
it's not a trivial transformation and faking it kernel side won't be any
better than faking it in user space - it may well even be a worse fake.

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