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