[linux-dvb] DVB-S2 API vs. HVR4000: When?

Steven Toth stoth at linuxtv.org
Thu Nov 1 03:10:57 CET 2007

Manu Abraham wrote:
> Steven Toth wrote:
>> Johannes Stezenbach wrote:
>>> Hi,
>>> On Tue, Oct 30, 2007, Manu Abraham wrote:
>>>> Johannes Stezenbach wrote:
>>>>> three weeks have passed since Steve expressed his
>>>>> discomfort with the HVR4000 merge being blocked
>>>>> waiting for multiproto.
>>>> Before i state anything, Current DVB-S2 API status:
>>> [snip]
>>> Thanks, that's useful.
>> Yes.
>>>>> Can you give us a time frame for when the multiproto
>>>>> merge will happen?
>>>>> Or, alternatively, can we split multiproto into
>>>>> two repositories, one with API + dvb-core changes
>>>>> and one (on top of it) with the STB0899 driver?
>>>> It can be either way, which one of the following do you think is
>>>> better in your view ?
>>>> (1) DVB-S2 API partly merged now and the rest of the S2 API later.
>>>> (2) Complete event list update and VCM and merge that also alongwith.
>>>> in either case it can be with or without the STB0899 driver.
>>>> What do you think ?
>>> I'd prefer to address the remaining API issues first, however
>>> what I primarily want to avoid is that Steve rewrites the
>>> HVR4000 driver to a competing API proposal due to
>>> frustration with the lack of progress.
>> Agreed.
>>> IMHO there should be a clear path of actions for Steve
>>> (or whoever else wants to help) to do that would allow merging
>>> the HVR4000 driver. I.e. instead of having to wait for some
>>> event beyond his control there should be a checklist, and
>>> the merge can happen when all items are resolved.
>>> Or something like that. Preferably Steve would comment
>>> how he'd like to go forward.
>> If these are new API's then I suspect the HVR4000 doesn't use them. I
>> would agree it makes sense to define them, but depending on their focus
>> they may not need to be implemented and should not be considered a
>> roadblock to an alpha release.
>> If they don't impact core functionality then I see no reason why this
>> cannot be defined now, but implement (and refined) later during the test
>> cycle. (I'm expecting testing to be a very long process, because we'll
>> need to encourage the VDR/MythTV/Other applications groups to begin
>> integration).
>> I am a realist. I don't expect the first tree will be perfect. I am
>> expecting some change. I am expecting apps devs/testers to find bugs and
>> problems which will cause us to rethink some parts of the multiproto
>> core and it's S2 drivers.
>> No doubt the VDR and MythTV folks will also have something to say and
>> that may impact the API also. We need to pay respect to the opinions of
>> the applications developers.
>> I don't think the first release needs to be perfect.
>> I think if the current API is good enough to support the needs of
>> Myth/VDR then that's something we can start with. Release early, release
>> often.
> It is not how the APi is good enough to support the needs of MythTV or VDR, 
> but how the API can be considered as a guide for the application developers 
> to understand how to talk to a DVB-S2 device
>> Manu, this is your patch and I respect your work, how would you suggest
>> we proceed?
> There does exist a ported version of VDR to the new API. The current situation 
> is that the S2 devices cannot be tuned to certain frequencies because of the 
> use of Backward compatible modes, ie the API, nor the drivers currently do 
> support them.
> Give application developers a chance to mess up stating that the API is out, 
> eventually what will happen is: example look at people crying out on 
> mythtv issues with regards to DVB devices. I have had quite some experiences
> trying to make application developers understand what they do wrong.
> I am waiting to hear from other developers as well, whether they would like to
> do whether to do 
> (1) partial DVB-S2 API support now and the rest of the DVB-S2 API later.
> (2) DVB-S2 API what it needs to tune to all the transponders at least
> Look, this is not the question of the HVR4000 or the STB0899 alone, it will affect 
> all future devices. As Johannes said, what goes into the API (user ABI) is permanent,
> it won't change. It is something that will be set in stone as opposed to the driver 
> internal API. (The driver API we can change, but not the ABI) What we are looking at 
> is the API-ABI
> Let me cite certain examples of such large scale screwups where people are stuck:

You've miss-interpreted my comments.

I suggested that the API should be defined, but not necessarily 
implemented. I was suggesting that we define enough API to generate a 
test tree and make some progress. Supporting your earlier statement, I 
suggested that the small amount of unimplemented API (which you 
suggested was inconsequential) could be implemented while other 
developers were testing the core TV functionality.

I.e. This becomes a group effort, not a Manu effort.

I never suggested the test tree would get merged, in fact I went out of 
my way to suggest that the process of testing would likely raise various 
design issues and/or bugs. I clearly outlined that I'm a realist and I 
expected this testing phase to cause change.

I thought I'd made myself clear.

I ended my previous email respectfully and repeated Linus's mantra. I 
was assuming your response would be positive.

Instead you've launched into a patronizing tirade and none of this 
ingratiates you with the other developers, it only stands in the way of 
progress and demonstrates the attitude we've witnessed over the last 
12-18 months re: multiproto.

I don't think I have anything else to say on the subject of multiproto, 
until you see fit to deliver publically your 'marvelous multiproto 
invention - all things under one roof', no doubt to the sound of 
trumpets, gasps and country wide applause.

I'm wasting my time here.

- Steve

More information about the linux-dvb mailing list