From: Andreas Oberritter <obi@linuxtv.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: VDR User <user.vdr@gmail.com>, HoP <jpetrous@gmail.com>,
Mauro Carvalho Chehab <mchehab@redhat.com>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Date: Sat, 03 Dec 2011 19:17:21 +0100 [thread overview]
Message-ID: <4EDA67B1.0@linuxtv.org> (raw)
In-Reply-To: <20111203174247.0bbab100@lxorguk.ukuu.org.uk>
On 03.12.2011 18:42, Alan Cox wrote:
> On Sat, 3 Dec 2011 09:21:23 -0800
> VDR User <user.vdr@gmail.com> wrote:
>
>> On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter <obi@linuxtv.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?
Yes.
>> 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.
USB tuners may be removed anytime during any ioctl, too. Handling such
error cases is therefore already a requirement, at least for
hotplug-capable software.
> 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.
It's certainly not suitable for every possible use case in the world.
For many, however, I think it's the optimal solution.
Regards,
Andreas
next prev parent reply other threads:[~2011-12-03 18:17 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-30 21:38 [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage? HoP
2011-11-30 21:52 ` Michael Krufky
2011-12-01 0:09 ` Andreas Oberritter
2011-12-01 11:04 ` Mauro Carvalho Chehab
2011-12-01 14:58 ` HoP
2011-12-01 17:38 ` Mauro Carvalho Chehab
2011-12-01 19:59 ` HoP
2011-12-01 20:38 ` Mauro Carvalho Chehab
2011-12-01 22:55 ` Andreas Oberritter
2011-12-02 11:14 ` Mauro Carvalho Chehab
2011-12-02 11:40 ` Rémi Denis-Courmont
2011-12-02 11:48 ` Andreas Oberritter
2011-12-02 12:05 ` Rémi Denis-Courmont
2011-12-02 11:57 ` HoP
2011-12-02 17:33 ` Mauro Carvalho Chehab
[not found] ` <3D233F78EE854A4BA3D34C11AD4FAC1FDD141F@nasanexd01b.na.qualcomm.com>
2011-12-05 18:16 ` V4L2 driver node directory structure under /video directory Mauro Carvalho Chehab
2011-12-02 17:49 ` [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage? Rémi Denis-Courmont
2011-12-02 18:16 ` Andreas Oberritter
2011-12-02 18:28 ` Andreas Oberritter
2011-12-02 23:19 ` Alan Cox
2011-12-03 0:37 ` HoP
2011-12-05 10:21 ` Florian Fainelli
2011-12-05 14:28 ` HoP
2011-12-05 15:16 ` Alan Cox
2011-12-05 15:18 ` Michael Krufky
2011-12-06 0:16 ` HoP
2011-12-05 17:39 ` Mauro Carvalho Chehab
2011-12-05 20:41 ` Andreas Oberritter
2011-12-05 20:55 ` Alan Cox
2011-12-05 21:20 ` Andreas Oberritter
2011-12-05 21:54 ` Alan Cox
2011-12-06 11:18 ` Mark Brown
2011-12-06 12:01 ` Andreas Oberritter
2011-12-06 13:10 ` Mauro Carvalho Chehab
2011-12-06 13:35 ` Andreas Oberritter
2011-12-06 14:13 ` Mauro Carvalho Chehab
2011-12-06 14:38 ` Andreas Oberritter
2011-12-06 15:06 ` Mauro Carvalho Chehab
2011-12-06 15:36 ` Manu Abraham
2011-12-06 11:21 ` Mark Brown
2011-12-06 12:01 ` Andreas Oberritter
2011-12-06 14:19 ` Mark Brown
2011-12-06 14:48 ` Andreas Oberritter
2011-12-07 13:49 ` Mark Brown
2011-12-07 14:01 ` Andreas Oberritter
2011-12-07 16:10 ` Mark Brown
2011-12-07 16:56 ` Andreas Oberritter
2011-12-07 16:58 ` Andreas Oberritter
2011-12-07 21:48 ` Patrick Dickey
2011-12-07 22:53 ` Honza Petrouš
2011-12-07 23:24 ` Peter Kolta
2011-12-07 23:55 ` Andreas Oberritter
2011-12-11 18:45 ` Peter martin
2011-12-12 10:31 ` Alan Cox
2011-12-06 17:19 ` Manu Abraham
2011-12-06 0:07 ` HoP
2011-12-06 13:22 ` Mauro Carvalho Chehab
2011-12-06 13:49 ` Andreas Oberritter
2011-12-06 14:19 ` Rémi Denis-Courmont
2011-12-06 15:05 ` Andreas Oberritter
2011-12-06 14:20 ` Mauro Carvalho Chehab
2011-12-06 15:00 ` Andreas Oberritter
2011-12-06 17:35 ` HoP
2011-12-03 16:13 ` Andreas Oberritter
2011-12-03 16:42 ` Alan Cox
2011-12-03 17:38 ` Andreas Oberritter
2011-12-03 17:21 ` VDR User
2011-12-03 17:42 ` Alan Cox
2011-12-03 17:48 ` Devin Heitmueller
2011-12-04 23:54 ` HoP
2011-12-03 18:13 ` Hans Petter Selasky
2011-12-05 0:05 ` HoP
2011-12-03 18:17 ` Andreas Oberritter [this message]
2011-12-03 23:30 ` Walter Van Eetvelt
2011-12-04 0:14 ` VDR User
2011-12-04 14:44 ` Alan Cox
2011-12-04 23:22 ` HoP
2011-12-05 1:45 ` VDR User
2011-12-05 6:20 ` HoP
2011-12-01 11:50 ` Communication misunderstanding? (was: Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?) Patrick Boettcher
2011-12-01 12:33 ` [RFC] vtunerc: virtual DVB device Rémi Denis-Courmont
2011-12-01 14:39 ` HoP
2011-12-02 18:32 ` [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage? VDR User
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EDA67B1.0@linuxtv.org \
--to=obi@linuxtv.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jpetrous@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@redhat.com \
--cc=user.vdr@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.