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

Manu Abraham abraham.manu at gmail.com
Tue Apr 10 03:58:18 CEST 2007

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.


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

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


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.


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

> HTH,
> Johannes


More information about the linux-dvb mailing list