[linux-dvb] DVB API update

Manu Abraham abraham.manu at gmail.com
Tue Sep 18 23:32:10 CEST 2007


Felix Domke wrote:
>>> Why don't abstract the dvb layer from enduser applications and put a
>>> general library infront which does that version check and tries to
>>> keep things consistend to the end applications?
>> It is a nice idea, yes.
>> Two things, looking at
>> http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c
> dvbfe_set imposes a certain programming scheme (because it sleeps). This
>  is a total no-go for a generic library. I don't want a library telling
> me that I have to use threads (instead of poll()).
> 

It is not yet released, so one can have a change to it, without much
hassles. Would you like to take a bite at it ? Anything to make it
better is always much appreciated, whether we use it or not for current
applications.

> Other than that, I think it's fine, or better: it doesn't do any harm.
> At the moment, I can only see that it adds another layer of indirection,
> but no real gain.
> 
> Especially, such a library shouldn't be an excuse for a bad API.
> 
> And, what's the big difference between a userspace library and an API?
> In what situation will the additional wrapper layer help compatibility?
> If we add a feature, we have to update the library as well. If we can do
> that in a backward compatible way, can't we do the same on the API?
> 

Since the issue maintaining backward compatibility is maintaining the
size of the older struct, which we avoid by copying causing an
additional layer of indirection in the kernel (dvb-core) The indirection
is a bit distributed to the library, such that it doesn't look ugly or bad.

In any case if we need backward compatibility, we need the indirection
somewhere. The only idea was to keep that in userspace, such that we
don't shoot ourselves in the foot.

Another thought was that an application using the library would be
usable straight away with multiple API's.
When the initial move was done, there were some thoughts of using some
other API's as well, hence the user_to_kapi definitions, ie the
indirection is handled in a nice way.

> I agree that it will help at this very moment, but as soon as
> applications need to deal  with different library versions, we have the
> same trouble again. Or did I misunderstand something? What can a library
> do what an API cannot do?

The idea was that the kernel change would not be visible to the end user
because of the additional indirection

> The alsa situation is a bit different - the alsa kernel api is very
> low-level, and needs some bells and whistles for easier usage. DVB is,
> fortunately, much easier to use. Our existing API is fine. (Agreed, if
> we ever add DMA buffers, we might need some helper app.)
> 
> Where I believe that we need a userspace helper is video processing (for
> handling records and proper playback using HW decoders), but for the
> frontend (or demux)?
> 

You don't get anything much large from it, except a layer of indirection
and a bit simplicity, such that the end application need not bother what
kernel API exits.

Manu




More information about the linux-dvb mailing list