[linux-dvb] Re: Hybrid tuner proposal (V4L/DVB)

Markus Rechberger mrechberger at gmail.com
Tue Apr 10 10:43:02 CEST 2007


On 4/10/07, Manu Abraham <abraham.manu at gmail.com> wrote:
> Johannes Stezenbach wrote:
>
> > In the discussions one month ago I had the impression that serveral
> > people agreed on this or at least wanted to help to do the
> > necessary work to get this merged.
> >
>
> whoever said anything got flamed, literally.
>
> http://linuxtv.org/pipermail/v4l-dvb-maintainer/2007-February/003623.html
>
> (i remember providing advice on this, private mails, over IRC etc, long
> time back even before i did a RFC, but it got so twisted the
> communication, that it was portrayed as though i was sabotaging
> someone's project. Hence i went silent after couple of people adviced
> just keep quiet on the same)
>

no this was mainly against someone else who insisted to look at
something that will not improve anything. I think you forget that my
code wasn't written in 2007 and in early 2006 I already asked if
someone has ideas about it.
http://v4l.videotechnology.com/irc/v4l/2006/03/02
I did all the work with help of a few others who contacted me privatly
and tested the code. From the v4l side only Mauro really gave me some
feedback, everyone else had other things to do or in your case didn't
want to participate.
And surprisingly Mauro also has different ideas about such a
framework.. so there are 4 developers with possibly 4 different
solutions but only one (and that was the RFC I started on the ML
without any participation) got realized for the xc3028 back then, and
previous attempts of other people to implement such tuners went
another way too (back then the situation was easier because of the 4
byte tuning code).
So now you come up with your code, it's fine but late. Also not
talking/asking me about feedback while developing such a framework is
also ignorant, since I've seen issues which you aren't aware of yet.
If someone thinks I'll adapt the code I've worked on for years with
other people he'll be wrong.

> > All private comments to Markus are fine, but if there's
> > any interest in getting this stuff merged, you need to show
> > it publicly.
> >
>
> I did not want to touch or comment on the em28xx/xc3028 after i was told
> to stay away.

for the reason of general unfriendlyness. As I wrote in the DVB
Maintainer thread I don't like that people just write your code is
bad, I mean I was ok with the mail calling the approach nonsense back
then because this basically showed up that some people who write DVB
drivers also disagree and have different ideas.

> In spite of all the flames and flamed private mails, i decided to put
> things in a standard well defined way, such that newer devices will not
> be affected the same way.
>
>
> > Any comments on the code are good. Not saying anything is bad.
> >
>
> What i have put as an RFC for fixing such issues
>
> https://www.redhat.com/mailman/private/video4linux-list/2007-April/msg00022.html
> http://marc.info/?l=linux-video&m=117571761928085&w=2
>
> A driver for illustrational purposes, with patches for both subsystems
> which does neither duplicate things nor make one subsystem dependant on
> the other, while still being light. It also addresses issues such as
> concurrent accesses, subsystem A accessing the device while subsystem B
> has a communication going on and vice versa.
>

it could affect less but we want to modularize the v4l tuners anyway.

> https://www.redhat.com/mailman/private/video4linux-list/2007-April/msg00047.html
> http://marc.info/?l=linux-video&m=117613833119350&w=2
>
> > FWIW, I very briefly looked at
> >
> http://mcentral.de/hg/~mrec/v4l-dvb-experimental/file/d1e8753a491b/linux/include/media/v4l_dvb_tuner.h
> > and I think the V4L_OPS macro is invalid because it yields a pointer
> > to a variable on the stack which just went out of scope.
> > This might work by accident, but IMHO gcc is allowed to
> > reuse the stack space for something else immediately after
> > the closing brace.
>
>
> Not only that.

there's absolutly nothing wrong with it, someone might say that it
doesn't look nice but that's all about it. I know what I did there,
and I already commented it.
It's about converting the parameters to another format temporary.

> v4l_dvb_tuner does complete duplication of
> dvb_frontend.h. With such an approach when an API update is performed,
> such things will break, causing high maintenance and of course not
> forgetting the flames again.  Issues with concurrent access also persists.
>

it's also about modularization, I don't see where it duplicates
significant parts of the code. it also works well with xc3028 v4l only
drivers or xc3028 dvb only drivers without too much overhead finally.
If someone wants to add another hybrid module it's very easy that way,
significant easier than your current approach since there's one
interface.
The code got cut out, changed and now it works with both frameworks.
I still have several problems with that framework, and I know you have
them too because you have no full featured driver packed into your
framework neither has anyone tested it yet. Problems will come up if
you have a closer look at the i2c part of that driver.
Issues are documented on the em28xx ML.

which issues about concurrent access?

In case of the xc3028 locking is performed on a device node based
level. It's only possible to access the v4l or dvb device at a time.

Markus



More information about the linux-dvb mailing list