[linux-dvb] Future of Multiproto

Johannes Stezenbach js at linuxtv.org
Fri Oct 12 12:30:00 CEST 2007

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.
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.

> > 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.

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.

> > 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 
> else.

What? Please elaborate.

> > 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 mailing list