public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: "Hans Werner" <HWerner4@gmx.de>
To: Jelle De Loecker <skerit@kipdola.com>, linux-dvb@linuxtv.org
Subject: Re: [linux-dvb] [PATCH] Future of DVB-S2
Date: Fri, 29 Aug 2008 19:11:30 +0200	[thread overview]
Message-ID: <20080829171130.74790@gmx.net> (raw)
In-Reply-To: <48B828CF.6050306@kipdola.com>


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

Jelle De Loecker wrote up there and I moved it down here:
-------- Original-Nachricht --------
> Datum: Fri, 29 Aug 2008 18:50:23 +0200
> Von: Jelle De Loecker <skerit@kipdola.com>
> An: linux-dvb@linuxtv.org
> Betreff: Re: [linux-dvb] [PATCH] Future of DVB-S2

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

Jelle,
yes I know you're interested in the TT S2-3200, but the issues are the same for all the DVB-S2
cards (which are already numerous and popular). There is a multiproto driver for the HVR4000 too,
but in addition there are some drivers written by Steven and Darron which take different (and 
illuminating) approaches to providing DVB-S2 support. Once the issues blocking DVB-S2 support 
in the kernel are sorted out we should hope that all the out-of-kernel DVB-S2 drivers will move
into the kernel quickly, including the TT S2-3200 driver.  We need to break the deadlock as soon
as possible.
Hans


-- 
Release early, release often. Really, you should

GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

  reply	other threads:[~2008-08-29 17:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080821173909.114260@gmx.net>
     [not found] ` <20080823200531.246370@gmx.net>
2008-08-28 21:22   ` [linux-dvb] Future of DVB-S2 Jelle De Loecker
2008-08-29  5:36   ` P. van Gaans
2008-08-29  7:32     ` Jelle De Loecker
2008-08-29 14:08       ` Steven Toth
2008-08-29 15:43         ` [linux-dvb] [PATCH] " Hans Werner
2008-08-29 15:52           ` Michael Krufky
2008-08-29 16:03             ` Steven Toth
2008-08-29 18:26               ` Hans Werner
2008-08-29 18:34                 ` Steven Toth
2008-08-29 16:43             ` Hans Werner
2008-08-29 16:50               ` Jelle De Loecker
2008-08-29 17:11                 ` Hans Werner [this message]
2008-08-29 17:52                 ` Steven Toth
2008-08-29 18:52               ` Oliver Endriss
2008-08-29 19:15                 ` Manu Abraham
2008-08-29 23:46                   ` Jelle De Loecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080829171130.74790@gmx.net \
    --to=hwerner4@gmx.de \
    --cc=linux-dvb@linuxtv.org \
    --cc=skerit@kipdola.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox