[linux-dvb] Rationalising dvb-apps/lib[s] anyone?
philipp_subx at redfish-solutions.com
Tue Nov 8 23:17:19 CET 2005
Andrew de Quincey wrote:
>Hi, as I'm likely to start using these in the near future, I'd like to sort
>out the current situation. I would like to avoid a flamefest though
>Currently we have:
>OK, so I'm the worst offender with two copies of libdvbcfg :)
>I'd like to move dvb-apps/libs/libdvb2 and dvb-apps/libs/libsi2 into
>dvb-apps/lib. I would also like to rename libsi2 to "libucsi". Why "lib"
>instead of "libs"? Because I prefer "lib".
>I'd like to _stress_ that we will keep all code; although there appear
>to be functional overlaps it is all useful in different circumstances.
>I will also create a wiki page describing the advantages of the libs,
>something like the following:
>* libdvbcfg. Standalone library for dealing with various DVB configuration
>files in effort to have feature complete standardised file formats.
>* libdvben50221. Standalone library for EN50221/CAM control.
>* libdvbsi. Standalone library for DVB related SI parsing. This one is
>designed to provide an easy to use API. It parses SI structures into nice
>sane formats in memory, using malloc().
>* libdvb2. This is designed as a C replacement for the Metzler bros' C++
>"libdvb", since many projects do not wish to use C++. It is designed to be
>_great_ for simplifiying access to DVB devices, but may not be suited to all
>applications (e.g. for extreme embedded/custom stuff). This builds on the
>various other libraries.
>* libsi2. Standalone library for SI parsing. I would like to rename this to
>libucsi (lib-micro-si). Calling it "libsi2" is a bit of a misnomer since its
>not really a sequel to anything - its just a different way of doing things.
>Specifically it is designed for embedded systems where malloc()/free() are
>bad. Its API is not as nice to use as libdvbsi, but it parses SI structures
>directly in memory with no malloc()/free(). It also covers more than just
>"dvb" including complete coverage of all mpeg,dvb, and sometime in the
>future, atsc tables/descriptors.
I don't think malloc()/free() per se is bad. Especially when it's not done
extremely dynamically... we're talking about doing it once when an
application starts, and returning it all when it ends. Fragmentation and
leaks should be a minimal concern.
More of an issue would be the use of lots of stack space for copy
constructors, which C++ loves to use. They use alloca() aggressively,
which can tank your stack.
A while back, I sent some comments about how the libraries work,
and what might be done to improve them.
For instance, having applications ask for a type of adapter, and
having the system probe for all available (unused) adapters, detect
their type, and returning the matching kind. Why? Imagine the
following: you've got a tri-mode tuner card, and it's connected
to a Spaun Diseqc NxM switch... The source can be chosen
dynamically from off-the-air, cable, or satellite, and the front-end
can be dynamically selected to be DVB-T/ATSC, QAM256, or
8QPSK. Do you really want to burden the application with that
logic? And do you want to have each application handle that
configuration state differently?
I also think that we could do a better job abstracting the various
kinds of Diseqc support that applications use... whether one is
using a toroidal dish with a switch or a single LNB with a rotor,
this sort of detail should be contained in the configuration, but
abstracted away from the application.
Lastly, the configuration files could be more flexible, and more
human readable. Embedding "7" for the FEC rather than "7/8"
is less clear than it could be, and risks breaking should the enum
values change in a future release of the kernel.
All of the satellite information, position, positioning info for a
rotor or toroidal dish (i.e. which switch input, what stored position,
or what angular azimuth and elevation for a 1- or 2-axis position),
the frequencies, transponder numbers, beacon frequencies, sids,
aids, pids, vids, encoding and encryption methods, etc. should all
go into a single configuration file (but a structured, heirarchical one).
Priming and editting that file should be done by the dvb-apps package,
not by applications.
Applications should be patched to use a higher level abstraction of
the libraries (and indeed, developping these patches and re-verifying
that the applications continue to work would be a reasonable way to
confirm that the libraries are correct and functionally adequate).
>linux-dvb mailing list
>linux-dvb at linuxtv.org
More information about the linux-dvb