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

Manu Abraham abraham.manu at gmail.com
Sun Feb 26 22:32:55 CET 2006

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_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 },
    { -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.

But what will the user need ? Just tune and forget, isn't it .. ? why 
should the user need to know about FE_CAN xyz .. ?

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.


More information about the linux-dvb mailing list