[linux-dvb] Future of Multiproto
abraham.manu at gmail.com
Fri Oct 12 13:01:53 CEST 2007
Johannes Stezenbach wrote:
> On Fri, Oct 12, 2007 at 11:56:21AM +0400, Manu Abraham wrote:
>> Johannes Stezenbach wrote:
>>> On Fri, Oct 12, 2007, Manu Abraham wrote:
>>>> Johannes Stezenbach wrote:
>>>>> Does that mean that Manu has no intentions to get
>>>>> his multiproto API changes merged?
>>>> It will be merged
>>> When? Why hasn't it been merged months ago when HVR4000 worked?
>> HVR4000 was struggling even recently howto handle pilots, because it
>> had a hard time trying to figure out how pilots worked. Eventually, the
>> implementation from the STB0899 had to be copied to the same, for it
>> to work. The reason being CX24116 being mostly RE'd, AFAIH.
> Drivers will always have bugs, so what? The hg log suggests that
> the pilots should also be in the API, but Steve had to wait for
> you to deliver an updated API and thus fixed it internally.
eh ? Pilot detection is an internal part of the driver, not part of the API.
> Within the scope of testing Steve could do the driver was
> presumably ready months ago -- I take Steve's word on this.
>>>>> (If so, then wtf was the point of doing them and keep
>>>>> everyone waiting? But I guess the "DVB API update" thread
>>>>> meant he isn't happy with it anymore.))
>>>> As i wrote, there are more things in the S2 specification, also
>>>> currently stuff like proper statistics cannot be done for example
>>> As I tried to tell you in one of my replies in the "DVB API update"
>>> thread statistics is totally independent of DVB-S2. And the
>>> "more things" were not spelled out in detail by you -- and
>>> why don't you just fix the API if you know something is missing,
>>> instead of saying "something's missing, can't merge yet"?
>> Please, Just look at the changesets for the same.
> I don't get it -- one mail you say something's missing,
> next mail you say already done.
maybe you want to read selectively
>>> I just can't understand why you were dragging this out so long,
>>> usually I would expect the desire of any developer is to get
>>> the code merged ASAP. With a working HVR4000 driver you could've
>> FYI, the STB0899 driver is much older than the HVR4000 driver, it has
>> been delayed because of
>> 1) too much noise on the ML (you had bit much to do with it)
>> 2) The feedback that resulted from the discussions on the ML, were
>> not sufficient for a complete API, eventually STM chipped in, was a
>> lot of struggle at my side too.
> Ugh -- the monster thread in May 2006 got so large because
> _you_ didn't believe me when I said that his API doesn't match
> my understanding of the DVB-S2 spec, and you were unable to
> explain to me how it works. So we needed to go through the
> spec together trying to figure out how it works. In the end
> I concluded the only sane to proceed is to finish writing
> a driver to find out if the API _really_ works, and to fix
> any API bugs you'd might encounter during driver implementation.
> And now you acknowledge that this was right, and you even
> had to ask STM for help.
I had go that way, because there was so much confusion added
by you into it.
> So I really don't understand your repeated accusations that
> I create "too much noise" or "unneccessary discussions".
>>> got the API and dvb-core changes merged months ago -- which would've
>>> allowed you to merge the STB0899 driver in CONFIG_EXPERIMENTAL
>>> status to expose it to a wider audience if you'd wanted to.
>> Your earlier statements resulted thus:
>> * go experimental
>> * no experimental
>> * go experimental
>> Looks like some square wave function. Are harmonics expected ?
> Here's a little trick question for you:
> Does CONFIG_EXPERIMENTAL apply to APIs visible to userspace?
>>> Instead you seem to have the desire to work on your private branch
>>> forever, adding patch upon patch to make it as big and important
>>> as possible.
>> Can you please point to the changesets which cause you to mention
>> "adding patch upon patch to make it as big and important as possible" ?
>> If you can't point that, it is fairly evident that you are blindly accusing me
>> and thereby blurting nonsense and sparking politics.
> Just a few lines above you said: "As i wrote, there are more things
> in the S2 specification, also currently stuff like proper statistics
> cannot be done for example". And see the "DVB API update" thread.
> Now you play the "what I say is irrelevant, only changesets count"
> game, and hurl the P-word at me once more. Thanks.
You accused me by stating: "adding patch upon patch to make it as big
and important as possible."
I asked you to show this in the changeset.
Now you fail to do so and try to trick/confuse people.
>>> Any not caring at all that you block Steve's work
>>> as a consequence.
>> hmm.. accusations again. ATM, Steve was/is prejudiced because of something
> What? Please elaborate.
Please read his reply to Herman.
>>> I asked you for your plans in this thread but I didn't get an answer.
>> I had mentioned the same earlier (not in this thread), maybe you missed
>> those mails or that you like to read selectively.
>> The basic idea is that STM contributed to many stuff, including comments
>> as how things should be done. Maybe you are not aware how you work
>> with a vendor for their devices and or when you have taken support from
>> them, you need their final approval.
>> Thus, before anything is done, i need to get a confirmation from STM as
>> well. I have asked STM as well, please read the inlined mail.
> STM's contributions are welcome, but we cannot allow them to block
> the merge of the HVR4000 driver. If they (or you) think the STB0899
> driver isn't ready, then your changes should be split so that the
> API and dvb-core changes can be merged with HVR4000 without dragging
> STB0899 into the merge.
>>> Anyway, I don't know what has been said on irc and I can't
>>> be bothered to read the irc logs. I really don't care if the DVB-S2
>>> API is done one way or the other, if you can't cooperate with Steve
>>> then you have to compete with him. IMHO the first one to have a fully
>>> working API + driver ready for merging wins. That's what I vote for.
>> HVR4000 specific S2 API ?
>>> The requirements to make it mergable are still the same
>>> as in Nov. 2005 when the DVB-S2 API was discussed first:
>>> - don't break backwards compat
>>> - add complete support for all DVB-S2 features, or at least
>>> allow missing features be added later in a backwards compatible way
>>> - don't be completely ugly (like the Reelbox hack)
>>> - don't repeat past mistakes and design it to allow easier backwards
>>> compatible extensions in the future (like e.g. for DVB-H)
>> Please do check in the tree whether you still have anything to NACK. If it is
>> ok, i will have another round of cleanups.
> I won't do it while it's in the "wait for STM or whatever" stage, I would
> maybe do it when you post your "it's ready for merge, please review" mail.
> But I'll also wait what Steve will be doing, and what others say.
> Currently I feel I'd be riding a dead horse if I'd put any work
> into reviewing your code.
More information about the linux-dvb