Fwd: [linux-dvb] [PATCH/RFC] add dvb-s2 support to frontend.h and
alannisota at gmail.com
Tue Apr 18 23:13:59 CEST 2006
I meant to send this to the list as well. Sorry.
---------- Forwarded message ----------
Date: Apr 18, 2006 2:11 PM
Subject: Re: [linux-dvb] [PATCH/RFC] add dvb-s2 support to frontend.h
On 4/18/06, Marcel Siegert wrote:
> On Tuesday 18 April 2006 19:27, Alan Nisota wrote:
> > That would allocate a bunch of space in the structure for future
> > expansion while allowing for minimal effort from the app side to
> > support both the new and old API with only a few #ifdefs. Sure it
> > isn't pretty, but I would expect it would help adoption go a lot
> > smoother.
> that is right actually.
> i'll think about it to clearify the advantages for myself.
Thanks. I do realize how frustrating this is. I would love to be
able to actually just have a solution and move on too, but at the same
time, I'd like there to be a chance that the myth guys actually accept
my S2 patch.
> you will get the messages just at compile time. and of course if you have e.g.
> -Werror within your c/c++ compiler flags, compilation will fail due to errors.
Many apps (and myth falls in this category) try very hard to keep the
number of warning messages at 0 (this makes it easy to spot
potentially erroneous new code). They really don't like warnings that
they can't do anything about.
> > I don't think it is right to expect userspace apps to be designed in a
> > specific way, and we shouldn't cause them extra work unless there is
> > no other reasonable solution IMHO.
> yes, that is true i your way of thinking. but, if you think a bit more, just this behaviour is
> rising up all the problems we have, isn't it?
Myth isn't really that bad (the dvb_paramteres stuff is regulated to 1
file). We still need a bunch of #ifdefs to conditionally add support
for S2 (because it directly accesses the capability definitions in
many places, and the S2 ones won't be defined. I am going to look
into creating a compatibility header file to define all S2 related
vars if they don't exist. This might make the code a lot cleaner.
But it would still be much easier if I could pass a dvb_parameter_new
structure to SET_FRONTEND (assuming that one of the supported
protocols was in use, and casted as dvb_parameters)), as it would
prevent a significant amount of code duplication,and make the code
much easier to read. The implementation I proposed would support
> following is just my personal opinion:
> "having api specific code at some small codepieces wouldn't bring up these _huge_ patches or
> your mentioned #ifdef #else #endif orgies for them.
> everybody should be free in his way to implement things, but also has to take the results, if they
> lead in much work."
That is nice in theory, but no one told the app developers that when
they were writing their apps. They didn't expect to have to deal with
these types of changes ever.
> ps. if my answer comes up in a "rough" way, don't take it too serious. i am working on different
> proposals for nearly 2 month now. everytime i think that we get a solution we can go for,
> someone comes up with another way of thinking :) i don't mind and keep on working until
> it is done. thanks for your participation alan.
I understand. My main purpose here is to deliver a driver for the
genpix8psk board. I've been trying to do so for several months as
well, and there are many users who would like to be able to use it
without the crude hacks I've had to give them in the mean time.
More information about the linux-dvb