[linux-dvb] a question of dvb style programming
domi.dumont at free.fr
Sat Mar 12 11:47:27 CET 2005
I have a kind of a (friendly) disagreement with Manu regarding
programming style for linux-dvb.
We currently disagree on the best way for ca_zap.
This small user land application is in charge of retrieving the pmt
info (i.e. an array of char) and create a ca_pmt messages
(i.e. another array of char).
Unfortunately, the data cannot be directly copied from the first array
to the seond array. Some kind of data treatment is required.
Currently, ca_zap uses a single loop to read the first array and write
the second array with a lots of counters, variables, and some tests to
handle the special cases that crept in.
Until now, this worked more or less fine.
But now, I need to factorize identical ca_desc from es_stream level to
program level. (Lest the ca_pmt message is too long to fit in 256
bytes). So ca_zap must now move data before copying them in the second
I've tried to implement this within ca_zap loop fiddling with all the
counters and variables but I felt like programming in brainfuck.
So far I've only managed an ugly hack to get some TPS channels
working, but it's not a solution that will work for other people.
So, I was thinking about re-writing ca_zap to use a set of
intermediate data structure that would a structured view of the data
to be stored in the ca_pmt message.
A first loop would read the pmt table and fill the intermediate data
structure. A second loop would read (and interpret) the intermediate
data structure to fill the set_pmt array of char.
IMHO, an intermediate data structure will make the program easier to
rad and understand. But it will be bigger.
Manu feels that this style of programming using intermediate storage
is frowned upon by the dvb community. Even for a user space program.
So, my question is, what does the dvb community prefers for ca_zap ?
The single do-it-all loop or the 2 steps way ?
Thanks for listening to my rant
More information about the linux-dvb