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

Manu Abraham abraham.manu at gmail.com
Wed Feb 8 00:08:22 CET 2006


Andrew de Quincey wrote:
>> 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)
>>     
>
> Yeah, I like this idea. If we keep on as we are, we're not really going to get 
> anywhere; it is becoming increasingly obvious that putting all the tuning 
> code in the kernel is hampering things a great deal. Many of the window 
> drivers I have examined have a similar architecture as well: raw device 
> access in kernel land, with the "interesting" stuff happening in userspace. 
>
> This way means we can support the old system so it provides minimum disruption 
> to existing users, but that we can also develop the more advanced stuff 
> required by others at the same time.
>
> I also like the idea of an i2c-like communications (but not i2c itself). i2c 
> itself is a very neat idea well understood by many people, so it makes sense 
> to mimic it. Obviously we can't use the kernel i2c layer directly because we 
> don't want to impose a dependency like that, since not all DVB devices 
> support i2c. 
>
> I suppose there might be an argument that we should "emulate" an i2c host for 
> non-i2c based DVB cards - personally I don't like this since IMO it would be 
> overkill, but I thought I should mention it for completeness.
>
> We could even do interesting things like have a python/perl interface to the 
> tuning system for rapid prototyping of tuning/frontend drivers - something 
> that sounds good to me.
>   

Yeah sounds cool, i think we should go for the dip then..


Thanks,
Manu





More information about the linux-dvb mailing list