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.
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.
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
