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

Ian Bonham ian.bonham at gmail.com
Thu Nov 1 19:34:27 CET 2007


Steve,
Does this mean you will be working on an alternative to MultiProto?
As an HVR4000 user I am following this thread closely as you might imagine.

Ian


On 11/1/07, Steven Toth <stoth at linuxtv.org> wrote:
>
> 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
>
>
>
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxtv.org/pipermail/linux-dvb/attachments/20071101/ab7c4213/attachment-0001.htm 


More information about the linux-dvb mailing list