[RFC] Userspace extensions, was Re: [linux-dvb] [patch] Add support for different tuning algorithms

Manu Abraham abraham.manu at gmail.com
Tue Feb 7 20:59:55 CET 2006


Hi,

Felix Domke wrote:
>
> Though I didn't test this, i strongly agree that we need this. I don't
> think it should be user selectable, though (except for the "SIMPLE"
> mode) - either the frontends supports a specific algorithm or not.
> Otherwise i fear that user applications start to workaround frontend
> driver bugs by selecting another algorithm...
>
> What's the exact difference between HW and ADAPTIVE? Isn't "it's done in
> hardware" the same as "it's done in the frontend driver", as far as the
> API is concerned?
>
> Some frontends support blindscanning, but require heavy software support
> for this (Fujitsu mb86a15 for example). Such code is not really suitable
> in the kernel (it sleeps, includes complicated algorithms etc.), so i
> think the best would be to make it a userspace library with frontend
> specific private ioctls, providing more or less direct register (or even
> i2c) access. What do you think?
>   

After a while, i would like to continue this discussion from where we 
left off last time. In this regard i did some basic homework ( no code 
yet )
but did come to the thoughts that a userspace library would be indeed 
the solution. In such a case i was drawn to the conclusion that a 
userspace i2c like extension which interfaces from the kernel to the 
userspace in such a manner that it interfaces to the Host Bridge directly.
Why i would think that a generic i2c interface probably might not be the 
solution is because almost all Host Bridges have General Purpose Input 
Output (GPIO) for controlling some peripherals. for ex. frontends.

Under such a circumstance i made my ideas into block diagrams for easier 
self explanation, without too many words.

But in any case i would like to make a small outline on the very same. 
We could add just 2 IOCTL's to the existing API for making it compatible 
with applications such that applications can choose between these two 
and or switch between the interfaces.
Currently i came to a conclusion something like this.

http://www.thadathil.net/dvb/msg_transfer_interface/interface_desc.txt


There are other advantages more than what was discussed earlier on this 
aspect than just tuning algorithms. Some of the advantages are

* we don't loose anything as all these communications that are exchanged 
are low speed communications
* lesser bloat in kernel
* being in userspace, things can be easily debugged
* cards with lot of cross definitions can be easily implemented, without 
the need of huge arrays in kernel
* the application can get a better control of the drivers (the frontend 
thread could easily be in the application, rather being in the kernel) 
But will need to keep the existing one as it is for compatibility reasons.
* userspace can handle math libraries compared to kernel.
* we can do tuning algorithms specific to frontends too.(such that we 
can make use of the hardware features)


I would like to know what you guys think about this.


Thanks,
Manu









More information about the linux-dvb mailing list