cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.14-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-5.slh.4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-5.slh.4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-5.slh.4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-5.slh.4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-5.slh.4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-5.slh.4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-5.slh.4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-5.slh.4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-5.slh.4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-5.slh.4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-5.slh.4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-5.slh.4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin

Re: cron job: media_tree daily build: OK

Finally! It's producing an OK result. It's been a long, long time since we managed that. Next step: continue whittling away at the sparse warnings/errors. Regards, Hans On 11/25/2013 04:32 AM, Hans Verkuil wrote: This message is generated daily by a cron job that builds media_tree

cron job: media_tree daily build: OK

version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.12-0.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git

OK

OK -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

OK

OK -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

OK

OK -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

OK

OK -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

OK

OK -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] [media] drxk: prevent doing something wrong when init is not ok

If firmware is not loaded for some reason, or if it is not ready yet, it makes no sense to honour to any DVB callbacks. So, return -EAGAIN, as the error condition may be temporary. If the device doesn't initialize, either because it requires a firmware or because there's an error during

Betr: Re: DiB0700 rc submit urb failed after reboot, ok after replug

[6.517631] rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-4/rc/rc0 [6.517821] dvb-usb: schedule remote query interval to 50 msecs. [6.517825] dvb-usb: Pinnacle PCTV 73e SE successfully initialized and connected. [6.517951] dib0700: rc

Re: Betr: Re: DiB0700 rc submit urb failed after reboot, ok after replug

On 06/26/2012 10:43 PM, cedric.dew...@telfort.nl wrote: [6.517631] rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-4/rc/rc0 [6.517821] dvb-usb: schedule remote query interval to 50 msecs. [6.517825] dvb-usb: Pinnacle PCTV 73e SE successfully

Re: DiB0700 rc submit urb failed after reboot, ok after replug

On 06/23/2012 10:43 AM, cedric.dew...@telfort.nl wrote: [6.517631] rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-4/rc/rc0 [6.517821] dvb-usb: schedule remote query interval to 50 msecs. [6.517825] dvb-usb: Pinnacle PCTV 73e SE successfully

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

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

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: Your assertatation that applications should ignore the underlying transport (which seems to be a big part of what you're saying) isn't entirely

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

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On 07.12.2011 17:10, Mark Brown wrote: a simple loopback in the style of FUSE which bounces the kernel APIs up to userspace for virtual drivers would make sense. That's exactly what vtunerc is. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On 07.12.2011 17:10, Mark Brown wrote: 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

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

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: Your assertatation that applications should ignore the underlying transport (which seems to be a

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

2011/12/7 Patrick Dickey pdickeyb...@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: Your assertatation that applications should

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On 07.12.2011 22:48, Patrick Dickey wrote: 4 (and the reason I decided to chime in here). This email sums everything up. Mark is pointing out that someone may want to use this in a non LAN setting, and they may/will have problems due to the Internet (and their specific way of accessing it).

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote: On 05.12.2011 21:55, Alan Cox wrote: The USB case is quite different because your latency is very tightly bounded, your dead device state is rigidly defined, and your loss of device is accurately and immediately signalled.

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote: On 05.12.2011 18:39, Mauro Carvalho Chehab wrote: When you put someone via the network, issues like latency, package drops, IP congestion, QoS issues, cryptography, tunneling, etc should be taken into account by the

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On 06.12.2011 12:18, Mark Brown wrote: On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote: On 05.12.2011 21:55, Alan Cox wrote: The USB case is quite different because your latency is very tightly bounded, your dead device state is rigidly defined, and your loss of device is

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On 06.12.2011 12:21, Mark Brown wrote: On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote: On 05.12.2011 18:39, Mauro Carvalho Chehab wrote: When you put someone via the network, issues like latency, package drops, IP congestion, QoS issues, cryptography, tunneling, etc

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On 06-12-2011 10:01, Andreas Oberritter wrote: On 06.12.2011 12:18, Mark Brown wrote: On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote: On 05.12.2011 21:55, Alan Cox wrote: The USB case is quite different because your latency is very tightly bounded, your dead device state

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

for DVB-C tune? With strace. See how many ioctl's are called for each tune. Ok, perhaps scandvb is badly written, but if your idea is to support 100% of the applications, you should be prepared for badly written applications. $strace -e ioctl scandvb dvbc-teste scanning dvbc-teste using '/dev

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On 06.12.2011 14:10, Mauro Carvalho Chehab wrote: On 06-12-2011 10:01, Andreas Oberritter wrote: On 06.12.2011 12:18, Mark Brown wrote: On Mon, Dec 05, 2011 at 10:20:03PM +0100, Andreas Oberritter wrote: On 05.12.2011 21:55, Alan Cox wrote: The USB case is quite different because your latency

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

-hack works. But you surelly didn't try to do it at all. How do you find those 45 ioctls for DVB-C tune? With strace. See how many ioctl's are called for each tune. Ok, perhaps scandvb is badly written, but if your idea is to support 100% of the applications, you should be prepared for badly

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

, but the non-userspace daemon aware applications will know nothing about it, and this is the flaw on this design: Applications can't negotiate what network parameters are ok or not for its usecase. For a DVB API application it doesn't matter whether a tuning request fails with EIO because a USB

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On Tue, Dec 06, 2011 at 01:01:43PM +0100, Andreas Oberritter wrote: On 06.12.2011 12:21, Mark Brown wrote: On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote: Are you serious? Lower networking layers should be transparent to the upper layers. You don't implement VPN or say

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

Le mardi 6 décembre 2011 15:49:11 Andreas Oberritter, vous avez écrit : You don't need to wait for write-only operations. Basically all demux ioctls are write-only. Since vtunerc is using dvb-core's software demux *locally*, errors for invalid arguments etc. will be returned as usual. That's a

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

-that-ugly-hack works. But you surelly didn't try to do it at all. How do you find those 45 ioctls for DVB-C tune? With strace. See how many ioctl's are called for each tune. Ok, perhaps scandvb is badly written, but if your idea is to support 100% of the applications, you should be prepared

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

nothing about it, and this is the flaw on this design: Applications can't negotiate what network parameters are ok or not for its usecase. How do you negotiate network parameters with your ISP and all involved parties on the internet on the way from your DSL line to some other peer? Let me answer

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On 06.12.2011 15:19, Mark Brown wrote: On Tue, Dec 06, 2011 at 01:01:43PM +0100, Andreas Oberritter wrote: On 06.12.2011 12:21, Mark Brown wrote: On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote: Are you serious? Lower networking layers should be transparent to the upper

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

are not treating me as partner for discussion. Otherwise you should try to understand how-that-ugly-hack works. But you surelly didn't try to do it at all. How do you find those 45 ioctls for DVB-C tune? With strace. See how many ioctl's are called for each tune. Ok, perhaps scandvb is badly

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On 06.12.2011 15:19, Rémi Denis-Courmont wrote: Le mardi 6 décembre 2011 15:49:11 Andreas Oberritter, vous avez écrit : You don't need to wait for write-only operations. Basically all demux ioctls are write-only. Since vtunerc is using dvb-core's software demux *locally*, errors for invalid

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

flow over the network and to return errors to vtunerc. Yes, you can do anything you want at the userspace daemon, but the non-userspace daemon aware applications will know nothing about it, and this is the flaw on this design: Applications can't negotiate what network parameters are ok

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

will know nothing about it, and this is the flaw on this design: Applications can't negotiate what network parameters are ok or not for its usecase. How do you negotiate network parameters with your ISP and all involved parties on the internet on the way from your DSL line to some other peer

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On Tue, Dec 6, 2011 at 7:49 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Dec 06, 2011 at 01:01:43PM +0100, Andreas Oberritter wrote: On 06.12.2011 12:21, Mark Brown wrote: On Mon, Dec 05, 2011 at 09:41:38PM +0100, Andreas Oberritter wrote: Are you serious? Lower

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

from the switch. If tuning fails, it has to retry anyway, even if all ioctls returned 0. Ok, the driver could be smarter than that, and some heuristics could be added into it, in order to foresee the likely error code, returning it in advance, and then implementing some asynchronous mechanism

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

Hello, On 12/03/11 01:37, HoP wrote: Hi Alan. 2011/12/3 Alan Coxa...@lxorguk.ukuu.org.uk: On Thu, 1 Dec 2011 15:58:41 +0100 HoPjpetr...@gmail.com wrote: Hi, let me ask you some details of your interesting idea (how to achieve the same functionality as with vtunerc driver): [...] The

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

Hi 2011/12/5 Florian Fainelli f.faine...@gmail.com: Hello, On 12/03/11 01:37, HoP wrote: Hi Alan. 2011/12/3 Alan Coxa...@lxorguk.ukuu.org.uk: On Thu, 1 Dec 2011 15:58:41 +0100 HoPjpetr...@gmail.com  wrote: Hi, let me ask you some details of your interesting idea (how to achieve

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

You know - I'm a bit confused. Somebody are pointing on double data copying (userspace networked daemon - kernel - application) issue and another one warn me to not start network connection from the kernel. But if it works for NFS or CIFS then it should not be so weaky, isn't it? And then

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On Mon, Dec 5, 2011 at 9:28 AM, HoP jpetr...@gmail.com wrote: Hi 2011/12/5 Florian Fainelli f.faine...@gmail.com: Hello, On 12/03/11 01:37, HoP wrote: Hi Alan. 2011/12/3 Alan Coxa...@lxorguk.ukuu.org.uk: On Thu, 1 Dec 2011 15:58:41 +0100 HoPjpetr...@gmail.com  wrote: Hi, let me

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On 05-12-2011 12:28, HoP wrote: And here is a new hack. I'm really tired from all those hack, crap, pigback ... wordings. What exactly vtuner aproach does so hackish (other then exposing DVB internals, what is every time made if virtualization support is developing)? The code itself no need

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On 05.12.2011 18:39, Mauro Carvalho Chehab wrote: On 05-12-2011 12:28, HoP wrote: And here is a new hack. I'm really tired from all those hack, crap, pigback ... wordings. What exactly vtuner aproach does so hackish (other then exposing DVB internals, what is every time made if

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

The USB case is quite different because your latency is very tightly bounded, your dead device state is rigidly defined, and your loss of device is accurately and immediately signalled. Quite different. Alan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On 05.12.2011 21:55, Alan Cox wrote: The USB case is quite different because your latency is very tightly bounded, your dead device state is rigidly defined, and your loss of device is accurately and immediately signalled. Quite different. How can usbip work if networking and usb are so

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

How can usbip work if networking and usb are so different and what's so different between vtunerc and usbip, that made it possible to put usbip into drivers/staging? Where usbip seems to have remained for a long time without actually being made useful or correct enough to progress. Meanwhile

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

I doubt that scan or w_scan would support it. Even if it supports, that would mean that, for each ioctl that would be sent to the remote server, the error code would take 480 ms to return. Try to calculate how many time w_scan would work with that. The calculus is easy: see how many ioctl's

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

Hi Michael 2011/12/5 Michael Krufky mkru...@linuxtv.org: On Mon, Dec 5, 2011 at 9:28 AM, HoP jpetr...@gmail.com wrote: Hi 2011/12/5 Florian Fainelli f.faine...@gmail.com: Hello, On 12/03/11 01:37, HoP wrote: Hi Alan. 2011/12/3 Alan Coxa...@lxorguk.ukuu.org.uk: On Thu, 1 Dec 2011

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

While I agree with your more broad view of the issue, I specifically talked about VDR. AFAIK Klaus has no intention of adding true server/client support to VDR, so for VDR users, this sounds like it could be a working solution without the strict limitations of streamdev. So fix Klaus rather

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

Hi. 2011/12/3 VDR User user@gmail.com: On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter o...@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

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

Devin, I perfectly remember your opinion regarding vtuner. 2011/12/3 Devin Heitmueller dheitmuel...@kernellabs.com: On Sat, Dec 3, 2011 at 12:42 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Sat, 3 Dec 2011 09:21:23 -0800 VDR User user@gmail.com wrote: On Sat, Dec 3, 2011 at 8:13 AM,

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

Hi, Some input from the sideline reading this discussion. As a FreeBSD'er I would very much like to see two things happen: - vtunerc goes into userspace like a client/server daemon pair using CUSE and can support _any_ /dev/dvb/adapter, also those created by CUSE itself. That means I could

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On Sun, Dec 4, 2011 at 3:22 PM, HoP jpetr...@gmail.com wrote: Well, initial report was made on vdr-portal because of our hardware announce, but you can be sure the same is true if server is build on any linux hardware. Here is some note:

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

Well, initial report was made on vdr-portal because of our hardware announce, but you can be sure the same is true if server is build on any linux hardware. Here is some note:

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

Hello Alan, On 03.12.2011 00:19, Alan Cox wrote: On Thu, 1 Dec 2011 15:58:41 +0100 HoP jpetr...@gmail.com wrote: Hi, let me ask you some details of your interesting idea (how to achieve the same functionality as with vtunerc driver): [...] The driver, as proposed, is not really a

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

FWIW, the virtual DVB device we're talking about doesn't have any networking capabilities by itself. It only allows to create virtual DVB adapters and to relay DVB API ioctls to userspace in a transport-agnostic way. Which you can do working from CUSE already, as has been pointed out or with

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter o...@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

Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?

On 03.12.2011 17:42, Alan Cox wrote: FWIW, the virtual DVB device we're talking about doesn't have any networking capabilities by itself. It only allows to create virtual DVB adapters and to relay DVB API ioctls to userspace in a transport-agnostic way. Which you can do working from CUSE

<    1   2   3   4   5   6   7   >