Johannes Stezenbach wrote: > Hi Manu, > > On Sat, Sep 15, 2007, Manu Abraham wrote: >> While being on the V3 frontend API overhaul, i found to much dismay that >> it would be much better to revamp V4 into a newer API version such as >> V5, rather than scratching with V3 for ages together, resulting in just >> unnecessary talks and discussions. > > It is beyond me why you think creating a new API would > result in less "unnecessary" discussions that improving > the existing API... :-) (Oh, here comes the flame thrower from Johannes with a smiley) With regards to improving the existing API, just see the past reactions and too many unnecessary discussions. It is too much work to get going with a running API. It is next to impossible with all those politics in. To make it simpler, the existing API is a bit broken too much. :) > Given that there already is well-discussed API enhancement > proposal for DVB-S2, affectionately but wrongly called > "multiproto" (MPE?), I don't know why you don't get this > merged first instead of making that task bigger and have > everyone wait longer for the end result? multiproto "did not" mean Multi Protocol Encapsulation, but just meant multiple delivery systems. The original naming carried on from the first patch. IIRC, it was Obi who said/(corrected) that it would be incorrect to term protocol and hence changed to delivery system, but the naming just stuck to it, that's all. (Confusion again) i wonder how we can get rid of all these confusion between people. ;-) You see why now, rather being affection ? The problem is that, after making something experimental, throwing it out to application authors stating here it is: the API update, again a fix to the API will make anyone furious, nobody wants to keep tinkering forever on the same thing. I would prefer to say mark it experimental in a tree dedicated to it, such that it is explicitly stated that it is not a permanent solution and in the background, the fixes required for the relevant can be done. Don't you think so ? If someone asked me to keep working on with changes every now and then i wouldn't be very happy, but if i were explicitly told, look this is what as far what it stands as of now, it is expected to change, for further support, that i could digest it a bit. Trying to put myself into someone else's shoes. That said there are newer devices taking advantage of the full specs. As we have seen as soon as there are devices, there are applications as well. Vendors don't spend their funds on something nonsense and that too a major chunk of it. Of course there are cases, but in this case i highly doubt your claim. Not making others wait longer, see down.. > IIRC my closing words in the DVB-S2 API discussion were > along the line of "we shouldn't merge an API without users > into mainline now, we should wait until the first driver which > uses it is ready and merge both at the same time". > That is because a) we generally shouldn't add APIs without > users, b) we shouldn't add APIs which are untested and > thus not proven to work. IIRC, You only wrote sometime earlier, why work on something useless such as DVB-S2. Why a change of thought ? :) > Ever since, everyone's just been waiting for your > "I'm ready with my driver, please merge" mail. I would be going on with an experimental tree after Wednesday. Still some more things to be polished in that CCM only case too. See the first few posts on this DVB API update thread, The way the current API is, well it is as good as no statistics, but just for kids play there are some numbers scrolling up and down, ie the statistics do not hold any value. Displaying some random numbers is not statistics. Had a discussion with Steven too on this, since he has a driver as well. Why this is experimental ? I guess you get all the answers from within this mail itself. Sometime back you were the person who was against merging the same, now that you seem to suddenly pull in all that you said crap a few mails back. Wow, what a contradiction in statements. I would like to see the other features of DVB-S2 go in as well, since there are newer devices using those features. But for that i wouldn't prefer to work with the V3 demuxer, but prefer to go with V4 which has the advantages of ZeroCopy at least. >> What i find interesting with the V4 API >> * A better demuxer > > But it's also overcomplicated and like MiHu explained not > targeted at PCI/USB cards. IMHO It would be useful to add > a simple version of the recording filters to the V3 demux. Copying around, i would like to avoid. With High bitrate streams etc, for HD streams the PC would be already saturated, i would like to cut down whatever unnecessary overheads that do exist. If you would like to fix that in V3, i would much appreciate. If you would just like to keep talking only, maybe lets then not talk too much about it. >> * ARIB extensions > > I don't see anyone writing a driver using that, so why bother? > Someone asked me over IRC a few weeks back on a demod, moreover i have a 13 seg tuner. (You have the sources for that driver from me, currently) > Given that we always need to stay backward compatible with > old API versions, I believe it is much easier to improve > the existing API in small incremental steps than to introduce > a completely new API. (While working on V4, we were always > thinking "hey, we can add backward compat later", but frankly > I don't see how this could've worked out.) Okay, suppose you have added backward compat, for the initial simpler aspect with regards to the frontend. The demuxer almost will need to be redone. Don't you think so at least, with regards to DVB-S2, exception CCM ? Please do not ignore other deliveries either (just because you do not have it), i plan to work on DMB as well very soon. There were people who asked me about ARIB, who got fed up trying to add in a driver for 13seg (a guy who was banned from the list) So when you have to spent efforts again after a while again and again, why not do it once for all ? I don't follow your argument that we have to have flamewars every now and then. Maybe you like them so much and blame others for it ? > For DVB-S2 the problem was: > - couldn't extend FE_SET_FRONTEND without breaking > backwards compat > - thus need new ioctl > - to not repeat the same mistake I proposed to add > "forward compatibility" so we could extend the > new ioctl later for DVB-H etc. (DVB-SH, DVB-T2 > and DVB-C2 anyone?) DVB.org has called for the papers currently for C2 and T2, basically the idea they have put up is to use LDPC/BCH instead of Reed/Solomon. Another year or 2 for DVB-C2 or T2. But even before that i guess we need to work for the hardware which do exist, rather than for devices the even the complete base specification is not yet released. Don't you think so ? Please don't snip away all these, i need an answer from you, why you think this way. Of course you are free not to reply on the main things but rather what you would just prefer to. We have ACM applications and DMB-T/H chips coming up. IMHO it would be better to go along with what the industry goes with rather than define our ways and goals, which results in completely broken approaches of doing things. > (V4L2 API does the same thing) Don't care what V4L2 is doing, but ATM more concerned about what's going on. You can't force what someone is doing on somebody else. "Life is not Black and White. It is different shades of Black and white causing different Gray levels" someone said that .. ;-) > See? Keep it simple. Do just one thing at a time. I don't see it. As i said, will you take charge in fixing the demuxer for complete S2 as well as other protocols ? (Since you had a larger hand in the whole mess created, what i mean here is that you maintained DVB for a long while) The point being: either you fix it or allow others to fix. Both you seem to mildly dislike, don't understand why. If so sounds fine to me. But as you said i am just doing one thing at a time. Currently CCM works, need to get ACM and other things working, maybe get DSS also going (demux support needed) HTH, Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
