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 >please! ;) > >Currently we have: >dvb-apps/lib/libdvbcfg >dvb-apps/lib/libdvben50221 >dvb-apps/lib/libdvbsi >dvb-apps/libs/libdvb2 >dvb-apps/libs/libdvbcfg >dvb-apps/libs/libsi2 > >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. > > >Opinions/suggestions please? > > 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). -Philip >_______________________________________________ > >linux-dvb@xxxxxxxxxxx >http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > >
