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