[linux-dvb] [PATCH] Future of DVB-S2

[Jelle De Loecker]

I wasn't really focusing the haupage drivers, more the multiproto 
drivers manu created.

I have a TT S2-3200.

You're talking about upcoming change in the HVR4000 world? Do you know 
anything about our little technotrend cards?

/Met vriendelijke groeten,/

*Jelle De Loecker*
Kipdola Studios - Tomberg



Hans Werner schreef:
>>> Now, to show how simple I think all this could be, here is a PATCH
>>>       
>> implementing what
>>     
>>> I think is the *minimal* API required to support DVB-S2.
>>>
>>> Notes:
>>>
>>> * same API structure, I just added some new enums and variables, nothing
>>>       
>> removed
>>     
>>> * no changes required to any existing drivers (v4l-dvb still compiles)
>>> * no changes required to existing applications (just need to be
>>>       
>> recompiled)
>>     
>>> * no drivers, but I think the HVR4000 MFE patch could be easily adapted
>>>
>>> I added the fe_caps2 enum because we're running out of bits in the
>>>       
>> capabilities bitfield.
>>     
>>> More elegant would be to have separate bitfields for FEC capabilities
>>>       
>> and modulation
>>     
>>> capabilities but that would require (easy) changes to (a lot of) drivers
>>>       
>> and applications.
>>     
>>> Why should we not merge something simple like this immediately? This
>>>       
>> could have been done
>>     
>>> years ago. If it takes several rounds of API upgrades to reach all the
>>>       
>> feature people want then
>>     
>>> so be it, but a long journey begins with one step.
>>>       
>> This will break binary compatibility with existing apps.  You're right
>> -- those apps will work with a recompile, but I believe that as a
>> whole, the linux-dvb kernel and userspace developers alike are looking
>> to avoid breaking binary compatibility.
>>     
>
> Michael,
> thank you for your comment.
>
> I understand, but I think binary compatibility *should* be broken in this case. It makes
> everything else simpler.
>
> I know that not breaking binary compatibility *can* be done (as in the HVR4000 SFE and
> MFE patches) but at what cost?  The resulting code is very odd. Look at multiproto which 
> bizarrely implements both the 3.2 and the 3.3 API and a compatibility layer as well, at huge cost
> in terms of development time and complexity of understanding. The wrappers used in the MFE
> patches are a neat and simple trick, but not something you would release in the kernel.
>
> If you take the position the binary interface cannot *ever* change then you are severely
> restricting the changes that can be made and you doom yourself to an API that is no longer
> suited to the job. And the complexity kills. As we have seen, it makes the whole process grind to a
> halt. 
>
> Recompilation is not a big deal. All distros recompile every application for each release (in fact much more frequently -- updates too), so most users will never even notice.  It is much better to make the right, elegant changes to the API and require a recompilation. It's better for the application developers because they get a sane evolution of the API and can more easily add new features. Anyone who
> really cannot recompile existing userspace binaries will also have plenty of other restrictions and
> should not be trying to drop a new kernel into a fixed userspace.
>
> I would be interested to hear your opinion on how we can move forward rapidly.
>
> Regards,
> Hans
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxtv.org/pipermail/linux-dvb/attachments/20080829/bb1edd89/attachment.htm