Re: Minimum kernel version supported by v4l-dvb

[Jean Delvare <khali@linux-fr.org>]

Hi Mauro,

Only answering points Hans didn't already answered (and I agree with
him):

On Fri, 20 Feb 2009 21:23:27 -0300, Mauro Carvalho Chehab wrote:
> On Wed, 18 Feb 2009 14:01:05 +0100
> Jean Delvare <khali@linux-fr.org> wrote:
> > Not necessarily something to be proud about. This only shows how slowly
> > v4l has evolved in the past few years. Big changes that should have
> > happen have been constantly postponed in the name of compatibility.
> 
> No change I'm aware of were postponed due to previous kernel compatibility.

I2C bus multiplexing support, including transparent support for I2C
gates, is waiting to be implemented since kernel 2.6.27. Unfortunately
it is fundamentally incompatible with the legacy i2c binding model, so
we have to clean this up first. As it happens, this will not happen
before 2.6.30 at best. That's a 6 month delay, which is essentially due
to the fact that the conversion of v4l drivers is lagging behind. While
I was able to convert all hwmon drivers quickly, and rtc drivers were
converted by other developers quickly as well, v4l drivers I couldn't
convert myself because of the backwards compatibility requirements.

As a matter of fact, I sent a patch converting the zoran driver to the
new i2c binding model in September 2008. It was working perfectly fine
for me. But it was breaking backwards compatibility, so Hans told me to
hold off and he would take care of the conversion the right way. He
just did last week... 5 months after my own code was ready.

What you see here is a delay of several months in getting a task done,
plus me wasting my time on code that was then thrown away because Hans
had to do it all over again in a different way. When things get to the
point where patches written for the upstream kernel have to be
discarded and rewritten from scratch for the external repository, I say
that things have become too complex. This is the point at which you
start losing contributions.

> (...)
> No. I'm saying that we should not exclude an user just because it uses a RHEL
> kernel (btw, there are some versions at RHEL aimed for desktop and notebooks
> also using 2.6.18).

And I claim, once again, that we should exclude such users, because you
can count them on the fingers of one hand worldwide. It's really not a
matter of desktop vs. server distribution. It is a matter of
Enterprise-grade distribution vs. home user distribution, and the
requirements and expectations attached to them. A home user running
RHEL on a recent desktop machine on which he/she intends to watch TV is
simply using the wrong tool for the job.

> > (...)
> > As a side note, I doubt that the v4l-dvb repository would always work
> > that well for enterprise distribution kernels anyway. All the tests are
> > based on the kernel version, but the enterprise kernels diverge a lot
> > over time from the upstream version they were originally based on, so I
> > wouldn't be surprised if things broke from times to times.
> 
> True, but, when something breaks, people complain and the support is added. The
> better way of adding a backport is by adding a small search string at
> v4l/scripts/make_config_compat.pl and adding the backport code at compat. This
> solves the issues with the distro kernels much better than just checking for a
> specific kernel version.

Ah, I didn't know about that script. The good news is that it means the
system is more robust than I thought. The bad news is that it is even
more complex than I thought...

Anyway, please don't keep track of my original request. All I was
really saying is that supporting both the legacy and the new i2c
binding models is next to impossible, because of the huge conceptual
difference between them, and for this reason we have to drop support
for kernels older than 2.6.22. Now you say that maybe we need to
rethink the v4l-dvb development model from the ground up. Maybe we do,
but that's a totally different issue.

Thanks,
-- 
Jean Delvare