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: <CAJbz7-1S6K=sDJFcOM8mMxL3t2JS91k+fHLy4gq868_9eUyS9A@mail.gmail.com>
Date:	Tue, 6 Dec 2011 01:07:20 +0100
From:	HoP <jpetrous@...il.com>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Florian Fainelli <f.fainelli@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andreas Oberritter <obi@...uxtv.org>,
	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?

> 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 are called by each frequency and multiply by the number
> of frequencies
> that it would be seek. You should then add the delay introduced over
> streaming the data
> from the demux, using the same calculus. This is the additional time over a
> local w_scan.
>
> A grouch calculus with scandvb: to tune into a single DVB-C frequency, it
> used 45 ioctls.
> Each taking 480 ms round trip would mean an extra delay of 21.6 seconds.
> There are 155
> possible frequencies here. So, imagining that scan could deal with 21.6
> seconds of delay
> for each channel (with it doesn't), the extra delay added by it is 1 hour
> (45 * 0.48 * 155).
>
> On the other hand, a solution like the one described by Florian would
> introduce a delay of
> 480 ms for the entire scan to happen, as only one data packet would be
> needed to send a
> scan request, and one one stream of packets traveling at 10GB/s would bring
> the answer
> back.

Andreas was excited by your imaginations and calculations, but not me.
Now you again manifested you 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? I still see only one ioctl
FE_SET_FRONTEND or v5+ variant FE_SET_PROPERTY.

Sorry, but, for example, szap tunes very close to local variant:

# time szap -c channels.conf -x Ocko
reading channels from file 'channels.conf'
zapping to 15 'ocko':
sat 0, frequency = 12168 MHz V, symbolrate 27500000, vpid = 0x00a0,
apid = 0x0050 sid = 0x1451
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
status 1f | signal d410 | snr d380 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
0.00user 0.00system 0:01.33elapsed 0%CPU (0avgtext+0avgdata 2000maxresident)k
0inputs+0outputs (0major+171minor)pagefaults 0swaps

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