[linux-dvb] [PATCH] 8PSK/BPSK DVB-S/S2 support

Manu Abraham abraham.manu at gmail.com
Sun Feb 26 23:45:02 CET 2006


Ralph Metzler wrote:
> Manu Abraham writes:
>  > Ralph Metzler wrote:
>  > > The API changes are not an argument. The user space library will also
>  > > have an API. You will have exactly the same problems with API changes.
>  > >   
>  > 
>  > The user space lib will have 2 API's, the driver API (which can be the 
>  > same as of now) and the user API, so in all the cases unless somebody 
>  > wants to fiddle around with the user interface , the user API still 
>  > remains the same. Only the driver API will change, ie the back-end of 
>  > the library. but this is not much of a consequence as far i can think. 
>  > One can think of something like the back-end drivers in dfb.
>  > Other than this an API for transferring the message across. In this case 
>  > the API's are separated..
>  > 
>  > An example how we can separate the Kernel and backend driver API's
>  > 
>  >  static int dvbfe_code_rate_to_kapi[][2] =
>  > {
>  >     { DVBFE_FEC_NONE, FEC_NONE },
>  >     { DVBFE_FEC_1_2, FEC_1_2 },
>  >     { DVBFE_FEC_2_3, FEC_2_3 },
>  >     { DVBFE_FEC_3_4, FEC_3_4 },
>  >     { DVBFE_FEC_4_5, FEC_4_5 },
>  >     { DVBFE_FEC_5_6, FEC_5_6 },
>  >     { DVBFE_FEC_6_7, FEC_6_7 },
>  >     { DVBFE_FEC_7_8, FEC_7_8 },
>  >     { DVBFE_FEC_8_9, FEC_8_9 },
>  >     { DVBFE_FEC_AUTO, FEC_AUTO },
>  >     { -1, -1 }
>  > };
>  > 
>  > we can use function pointers in a table to map between different Kernel 
>  > API's to one unified in Userspace. So even if the kernel API/backend API 
>  > changes the user API is still unaffected.
>
>
> Yes, but if you have new features (e.g. DVB-T2, DVB-S3, DVB-H4.7, ... 
> if there ever will be such things ...) you will also have to change 
> the user space API. Then you have exactly the same problems as 
> right now with DVB-S2 and the kernel API.
>
>   

But that will be limited to the interface between the back-end part of 
the library and the backend drivers. But this would not affect the user 
interface though.

>  
>  > But what will the user need ? Just tune and forget, isn't it .. ? why 
>  > should the user need to know about FE_CAN xyz .. ?
>
> If you provide everything from tuning to channel management 
> in this one library you can of course hide most of these changes.
> But if the application wants more low level access, it will be the same.
>
>   

Yes, if one needs compatibility the existing interface can be used too 
whether it is v3 or v4
But this will mean duplication of code in user space(back end drivers) 
and kernel space



>  > It will also be easier in the sense that people won't have to recompile 
>  > kernels in a fast changing manner, unless for new bridges etc. But it is 
>  > not that we see new bridges that often compared to frontends.
>
> That is true. Like I said, I am waiting to see if it will be able to
> handle all the quirks of the current and upcoming bridges.
>
>   

We are not touching the bridges, so that wouldn't matter probably , or 
we can have work arounds in the bridge ?

> Since some of the demod drivers I am and will be working on will have 
> to be binary blobs with no kind of kernel dependencies (like kernel
> includes) anyway this will also make no big differences to
> me. At least as long as those I2C routing issues can be properly
> handled ...
>   

Yeah, i will give some more thought into this aspect..

> It also still will not hurt to have some interim solution for DVB-S2
> in the meantime.
>
>   
True..


Manu




More information about the linux-dvb mailing list