I meant to send this to the list as well. Sorry. ---------- Forwarded message ---------- Date: Apr 18, 2006 2:11 PM Subject: Re: [PATCH/RFC] add dvb-s2 support to frontend.h and dvb_frontend.[h|c] 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 doing this. > 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. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
