linux-kernel - Re: [PATCH] DVB Satellite Channel Routing support for DVB-S

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D2B2BA6.7030009@linuxtv.org>
Date:	Mon, 10 Jan 2011 16:54:14 +0100
From:	Andreas Oberritter <obi@...uxtv.org>
To:	Thomas Schlöter <thomas.schloeter@....net>
CC:	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] DVB Satellite Channel Routing support for DVB-S

On 01/10/2011 04:07 PM, Thomas Schlöter wrote:
>>> I decided this should be supported by the kernel frontend code as it is impossible to send that special DiSEqC / voltage sequence from userspace.
>>
>> Why do you think that's impossible? There's a userspace implementation
>> in Enigma2.
> 
> I think the kernel implementation would be superior for two reasons:
> - There are some timing requirements regarding the 14/18V transitions and the DiSEqC message which could perform better directly from the frontend code,

Unless there's proof, I won't believe that. We're not talking about
nanoseconds, but milliseconds, and it's about setting registers of slow
I2C devices. The same timing requirements are valid for each and every
backwards compatible DiSEqC sequence, which is the most common setting.

> - In many TV recording applications there is no support for SCR and it would be harder to implement in these. For VDR, there is a patch which is difficult to configure and has some technical limitations. In MythTV and XMBC I could not find any support for SCR. Their Wiki pages or forums say, that there are no plans for Unicable support as it would take huge changes.

Many of these applications didn't or don't support DiSEqC 1.1
(uncommittted switches) or DiSEqC 1.2 (rotor commands) or USALS. Still,
we don't put this logic into the kernel to make their life easier. Don't
add unneeded complexity to the kernel.

Of course, one could decide to start a reusable library to take care of
that stuff. Honestly, I don't know whether such a library exists today.

If you find the patch was simple enough to be applied to the kernel, it
must be as simple to patch your favourite application, even in a
platform independent way (not taking into account the required changes
to the UI, which have to be done anyway).

Regards,
Andreas
--
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/