Minimum kernel version supported by v4l-dvb

Minimum kernel version supported by v4l-dvb

[Jean Delvare]

Hi Mauro,

These days I am helping Hans Verkuil convert the last users of the
legacy i2c device driver binding model to the new, standard binding
model. It turns out to be a very complex task because the v4l-dvb
repository is supposed to still support kernels as old as 2.6.16, while
the initial support for the new i2c binding model was added in kernel
2.6.22 (and even that is somewhat different from what is upstream now.)
This forces us to add quirks all around the place, which will surely
result in bugs because the code becomes hard to read, understand and
maintain.

In fact, without this need for backwards compatibility, I would
probably have been able to convert most of the drivers myself, without
Hans' help, and this would already be all done. But as things stand
today, he has to do most of the work, and our progress is slow.

So I would like you to consider changing the minimum kernel version
supported by the v4l-dvb repository from 2.6.16 to at least 2.6.22.
Ideal for us would even be 2.6.26, but I would understand that this is
too recent for you. Kernel 2.6.22 is one year and a half old, I
honestly doubt that people fighting to get their brand new TV adapter
to work are using anything older. As a matter of fact, kernel 2.6.22 is
what openSUSE 10.3 has, and this is the oldest openSUSE product that is
still maintained.

I understand and respect your will to let a large range of users build
the v4l-dvb repository, but at some point the cost for developers seems
to be too high, so there's a balance to be found between users and
developers. At the moment the balance isn't right IMHO.

Thanks,
-- 
Jean Delvare

Re: Minimum kernel version supported by v4l-dvb

[Laurent Pinchart]

Hi Jean,

On Tuesday 17 February 2009 14:23:27 Jean Delvare wrote:
> Hi Mauro,
>
> These days I am helping Hans Verkuil convert the last users of the
> legacy i2c device driver binding model to the new, standard binding
> model. It turns out to be a very complex task because the v4l-dvb
> repository is supposed to still support kernels as old as 2.6.16, while
> the initial support for the new i2c binding model was added in kernel
> 2.6.22 (and even that is somewhat different from what is upstream now.)
> This forces us to add quirks all around the place, which will surely
> result in bugs because the code becomes hard to read, understand and
> maintain.
>
> In fact, without this need for backwards compatibility, I would
> probably have been able to convert most of the drivers myself, without
> Hans' help, and this would already be all done. But as things stand
> today, he has to do most of the work, and our progress is slow.
>
> So I would like you to consider changing the minimum kernel version
> supported by the v4l-dvb repository from 2.6.16 to at least 2.6.22.
> Ideal for us would even be 2.6.26, but I would understand that this is
> too recent for you. Kernel 2.6.22 is one year and a half old, I
> honestly doubt that people fighting to get their brand new TV adapter
> to work are using anything older. As a matter of fact, kernel 2.6.22 is
> what openSUSE 10.3 has, and this is the oldest openSUSE product that is
> still maintained.

Dropping pre-2.6.22 support may not be an issue for desktop systems that 
probably already run newer kernel versions. It might be a different story for 
embedded systems, as many users are stuck with old vendor-provided kernels.

I have no idea how many users we're talking about, but I know that the UVC 
driver is used with a 2.6.10 kernel on an embedded system by at least one 
person.

> I understand and respect your will to let a large range of users build
> the v4l-dvb repository, but at some point the cost for developers seems
> to be too high, so there's a balance to be found between users and
> developers. At the moment the balance isn't right IMHO.

I won't vote against setting the minimum kernel version to 2.6.22, but we 
should at least be aware that embedded users, even if they're not very vocal, 
are lurking out there in the darkness of vendor-provided kernels.

Cheers,

Laurent Pinchart

Re: Minimum kernel version supported by v4l-dvb

[Hans Verkuil]

On Tuesday 17 February 2009 23:24:03 Laurent Pinchart wrote:
> Hi Jean,
>
> On Tuesday 17 February 2009 14:23:27 Jean Delvare wrote:
> > Hi Mauro,
> >
> > These days I am helping Hans Verkuil convert the last users of the
> > legacy i2c device driver binding model to the new, standard binding
> > model. It turns out to be a very complex task because the v4l-dvb
> > repository is supposed to still support kernels as old as 2.6.16, while
> > the initial support for the new i2c binding model was added in kernel
> > 2.6.22 (and even that is somewhat different from what is upstream now.)
> > This forces us to add quirks all around the place, which will surely
> > result in bugs because the code becomes hard to read, understand and
> > maintain.
> >
> > In fact, without this need for backwards compatibility, I would
> > probably have been able to convert most of the drivers myself, without
> > Hans' help, and this would already be all done. But as things stand
> > today, he has to do most of the work, and our progress is slow.
> >
> > So I would like you to consider changing the minimum kernel version
> > supported by the v4l-dvb repository from 2.6.16 to at least 2.6.22.
> > Ideal for us would even be 2.6.26, but I would understand that this is
> > too recent for you. Kernel 2.6.22 is one year and a half old, I
> > honestly doubt that people fighting to get their brand new TV adapter
> > to work are using anything older. As a matter of fact, kernel 2.6.22 is
> > what openSUSE 10.3 has, and this is the oldest openSUSE product that is
> > still maintained.
>
> Dropping pre-2.6.22 support may not be an issue for desktop systems that
> probably already run newer kernel versions. It might be a different story
> for embedded systems, as many users are stuck with old vendor-provided
> kernels.
>
> I have no idea how many users we're talking about, but I know that the
> UVC driver is used with a 2.6.10 kernel on an embedded system by at least
> one person.
>
> > I understand and respect your will to let a large range of users build
> > the v4l-dvb repository, but at some point the cost for developers seems
> > to be too high, so there's a balance to be found between users and
> > developers. At the moment the balance isn't right IMHO.
>
> I won't vote against setting the minimum kernel version to 2.6.22, but we
> should at least be aware that embedded users, even if they're not very
> vocal, are lurking out there in the darkness of vendor-provided kernels.

Embedded users tend to make a snapshot of a particular kernel/driver and 
they don't usually upgrade either one. I do think that we need to make a 
branch (can hg do that?) or a copy of the repository just before dropping 
support for older kernels. So people who need to compile for a pre-2.6.22 
kernel can still get older, but working sources.

But we are developing drivers for inclusion into the linux kernel, not 
providing an unpaid (!) service for the few people who cannot/will not 
upgrade to a newer kernel. Especially companies like Texas Instruments that 
are working on new v4l2 drivers for the embedded space (omap, davinci) are 
quite annoyed and confused by all the backwards compatibility stuff that 
we're dragging along. I find it much more important to cater to their needs 
than to support a driver on an ancient kernel for some anonymous company. 
If they need it, then pay someone to backport the driver.

And of course, I have to do way too much work to keep it all running on 
older kernels. It's really not what I want to spend my time on.

It's great to be able to support older kernels, but only as long as it is 
technically not too much of a burden. And that might mean that at some 
stage we have to stop supporting all or most of the older kernels if some 
core kernel change was made that would require a unreasonable amount of 
work to keep it running on older kernels.

By going to 2.6.22 we can at least go back to providing i2c drivers without 
too much compatibility obfuscation. A driver like wm8739 would look like 
this:

-----------------------------------------------
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 26)
static int wm8739_probe(struct i2c_client *client,
                        const struct i2c_device_id *id)
#else
static int wm8739_probe(struct i2c_client *client)
#endif
{
        struct wm8739_state *state;

	...
}

static int wm8739_remove(struct i2c_client *client)
{
        struct v4l2_subdev *sd = i2c_get_clientdata(client);

        v4l2_device_unregister_subdev(sd);
        kfree(to_state(sd));
        return 0;
}

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 26)
static const struct i2c_device_id wm8739_id[] = {
        { "wm8739", 0 },
        { }
};
MODULE_DEVICE_TABLE(i2c, wm8739_id);
#endif

static struct i2c_driver wm8739_driver = {
        .name = "wm8739",
        .command = wm8739_command,
        .probe = wm8739_probe,
        .remove = wm8739_remove,
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 26)
        .id_table = wm8739_id,
#endif
};

static int __init wm8739_init(void)
{
        return i2c_add_driver(&wm8739_driver);
}


static void __exit v4l2_i2c_drv_cleanup(void)
{
        i2c_del_driver(&wm8739ver);
}

module_init(wm8739_init);
module_exit(wm8739_cleanup);
-----------------------------------------------

So that's three #ifdef's per i2c driver. I would personally prefer to take 
2.6.26 as the cut-off point, but I suspect that's not going to happen.

I hope I'm not ranting too much, but these backwards compatibility 
constraints are really counter productive and slowing down progress. We're 
mostly unpaid volunteers and we should not have to spend time on this.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Minimum kernel version supported by v4l-dvb

[Mauro Carvalho Chehab]

On Tue, 17 Feb 2009 14:23:27 +0100
Jean Delvare <khali@linux-fr.org> wrote:

> Hi Mauro,
> 
> These days I am helping Hans Verkuil convert the last users of the
> legacy i2c device driver binding model to the new, standard binding
> model. It turns out to be a very complex task because the v4l-dvb
> repository is supposed to still support kernels as old as 2.6.16, while
> the initial support for the new i2c binding model was added in kernel
> 2.6.22 (and even that is somewhat different from what is upstream now.)
> This forces us to add quirks all around the place, which will surely
> result in bugs because the code becomes hard to read, understand and
> maintain.
> 
> In fact, without this need for backwards compatibility, I would
> probably have been able to convert most of the drivers myself, without
> Hans' help, and this would already be all done. But as things stand
> today, he has to do most of the work, and our progress is slow.
> 
> So I would like you to consider changing the minimum kernel version
> supported by the v4l-dvb repository from 2.6.16 to at least 2.6.22.
> Ideal for us would even be 2.6.26, but I would understand that this is
> too recent for you. Kernel 2.6.22 is one year and a half old, I
> honestly doubt that people fighting to get their brand new TV adapter
> to work are using anything older. As a matter of fact, kernel 2.6.22 is
> what openSUSE 10.3 has, and this is the oldest openSUSE product that is
> still maintained.
> 
> I understand and respect your will to let a large range of users build
> the v4l-dvb repository, but at some point the cost for developers seems
> to be too high, so there's a balance to be found between users and
> developers. At the moment the balance isn't right IMHO.

In my case, I use RHEL 5.3 that comes with 2.6.18. I need at least to have
compatibility until this version, otherwise it will be harder to me to test
things, since most of the time I need to run RHEL 5 kernel.

I know that other developers also use RHEL 5 on their environments.

Cheers,
Mauro

Re: Minimum kernel version supported by v4l-dvb

[Hans Verkuil]

On Wednesday 18 February 2009 01:08:23 Mauro Carvalho Chehab wrote:
> On Tue, 17 Feb 2009 14:23:27 +0100
>
> Jean Delvare <khali@linux-fr.org> wrote:
> > Hi Mauro,
> >
> > These days I am helping Hans Verkuil convert the last users of the
> > legacy i2c device driver binding model to the new, standard binding
> > model. It turns out to be a very complex task because the v4l-dvb
> > repository is supposed to still support kernels as old as 2.6.16, while
> > the initial support for the new i2c binding model was added in kernel
> > 2.6.22 (and even that is somewhat different from what is upstream now.)
> > This forces us to add quirks all around the place, which will surely
> > result in bugs because the code becomes hard to read, understand and
> > maintain.
> >
> > In fact, without this need for backwards compatibility, I would
> > probably have been able to convert most of the drivers myself, without
> > Hans' help, and this would already be all done. But as things stand
> > today, he has to do most of the work, and our progress is slow.
> >
> > So I would like you to consider changing the minimum kernel version
> > supported by the v4l-dvb repository from 2.6.16 to at least 2.6.22.
> > Ideal for us would even be 2.6.26, but I would understand that this is
> > too recent for you. Kernel 2.6.22 is one year and a half old, I
> > honestly doubt that people fighting to get their brand new TV adapter
> > to work are using anything older. As a matter of fact, kernel 2.6.22 is
> > what openSUSE 10.3 has, and this is the oldest openSUSE product that is
> > still maintained.
> >
> > I understand and respect your will to let a large range of users build
> > the v4l-dvb repository, but at some point the cost for developers seems
> > to be too high, so there's a balance to be found between users and
> > developers. At the moment the balance isn't right IMHO.
>
> In my case, I use RHEL 5.3 that comes with 2.6.18. I need at least to
> have compatibility until this version, otherwise it will be harder to me
> to test things, since most of the time I need to run RHEL 5 kernel.
>
> I know that other developers also use RHEL 5 on their environments.

Why should we have ugly and time consuming workarounds in our repository 
that hamper progress just to allow you to run RHEL 5? I'm sorry, that's no 
reason at all. I very much doubt other subsystem maintainers are stuck on 
2.6.18.

And anyway, there is no way you can do proper testing against the new i2c 
API on that old kernel. The loading and probing of i2c modules is quite 
different, so that's never representative of what kernels >= 2.6.22 do.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Minimum kernel version supported by v4l-dvb

[Mauro Carvalho Chehab]

On Wed, 18 Feb 2009 01:18:37 +0100
Hans Verkuil <hverkuil@xs4all.nl> wrote:

> On Wednesday 18 February 2009 01:08:23 Mauro Carvalho Chehab wrote:
> > On Tue, 17 Feb 2009 14:23:27 +0100
> >
> > Jean Delvare <khali@linux-fr.org> wrote:
> > > Hi Mauro,
> > >
> > > These days I am helping Hans Verkuil convert the last users of the
> > > legacy i2c device driver binding model to the new, standard binding
> > > model. It turns out to be a very complex task because the v4l-dvb
> > > repository is supposed to still support kernels as old as 2.6.16, while
> > > the initial support for the new i2c binding model was added in kernel
> > > 2.6.22 (and even that is somewhat different from what is upstream now.)
> > > This forces us to add quirks all around the place, which will surely
> > > result in bugs because the code becomes hard to read, understand and
> > > maintain.
> > >
> > > In fact, without this need for backwards compatibility, I would
> > > probably have been able to convert most of the drivers myself, without
> > > Hans' help, and this would already be all done. But as things stand
> > > today, he has to do most of the work, and our progress is slow.
> > >
> > > So I would like you to consider changing the minimum kernel version
> > > supported by the v4l-dvb repository from 2.6.16 to at least 2.6.22.
> > > Ideal for us would even be 2.6.26, but I would understand that this is
> > > too recent for you. Kernel 2.6.22 is one year and a half old, I
> > > honestly doubt that people fighting to get their brand new TV adapter
> > > to work are using anything older. As a matter of fact, kernel 2.6.22 is
> > > what openSUSE 10.3 has, and this is the oldest openSUSE product that is
> > > still maintained.
> > >
> > > I understand and respect your will to let a large range of users build
> > > the v4l-dvb repository, but at some point the cost for developers seems
> > > to be too high, so there's a balance to be found between users and
> > > developers. At the moment the balance isn't right IMHO.
> >
> > In my case, I use RHEL 5.3 that comes with 2.6.18. I need at least to
> > have compatibility until this version, otherwise it will be harder to me
> > to test things, since most of the time I need to run RHEL 5 kernel.
> >
> > I know that other developers also use RHEL 5 on their environments.
> 
> Why should we have ugly and time consuming workarounds in our repository 
> that hamper progress just to allow you to run RHEL 5? I'm sorry, that's no 
> reason at all. I very much doubt other subsystem maintainers are stuck on 
> 2.6.18.

The role idea of having compatibility code is to allow people to test with
distro kernels. If we decide do exclude one of the major distro, I don't see
why not dropping support for the other distros and older kernels. For
sure removing all backports will make developers happy, but this will reduce the
amount of users that can help with the development, testing the drivers and
providing us patches.

It would be much more easy to me to just drop all -hg trees with all backport
and out-of-tree compilation and stuck with my -git trees, just like other
sybsystem maintainers do, but I _do_ think that our community will suffer a lot
with this. So, let's keep supporting at least the latest kernel version used by
the major distros. So, for now, we should still keep support for 2.6.18.

> And anyway, there is no way you can do proper testing against the new i2c 
> API on that old kernel. The loading and probing of i2c modules is quite 
> different, so that's never representative of what kernels >= 2.6.22 do.

I can assure you that I2C with v4l/dvb drivers work fine with 2.6.18. I use here
with several drivers (uvc, bttv, saa7134, em28xx, ...).

As a normal user, I use skype regularly the latest uvc driver + 2.6.18 on RHEL5.

Of course, while developing, we should always test the drivers against the
latest upstream tree, but this don't reduce the value of allowing normal users
to use the latest drivers with their systems.

Cheers,
Mauro

Re: Minimum kernel version supported by v4l-dvb

[Hans Verkuil]

On Wednesday 18 February 2009 03:08:15 Mauro Carvalho Chehab wrote:
> On Wed, 18 Feb 2009 01:18:37 +0100
>
> Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > On Wednesday 18 February 2009 01:08:23 Mauro Carvalho Chehab wrote:
> > > On Tue, 17 Feb 2009 14:23:27 +0100
> > >
> > > Jean Delvare <khali@linux-fr.org> wrote:
> > > > Hi Mauro,
> > > >
> > > > These days I am helping Hans Verkuil convert the last users of the
> > > > legacy i2c device driver binding model to the new, standard binding
> > > > model. It turns out to be a very complex task because the v4l-dvb
> > > > repository is supposed to still support kernels as old as 2.6.16,
> > > > while the initial support for the new i2c binding model was added
> > > > in kernel 2.6.22 (and even that is somewhat different from what is
> > > > upstream now.) This forces us to add quirks all around the place,
> > > > which will surely result in bugs because the code becomes hard to
> > > > read, understand and maintain.
> > > >
> > > > In fact, without this need for backwards compatibility, I would
> > > > probably have been able to convert most of the drivers myself,
> > > > without Hans' help, and this would already be all done. But as
> > > > things stand today, he has to do most of the work, and our progress
> > > > is slow.
> > > >
> > > > So I would like you to consider changing the minimum kernel version
> > > > supported by the v4l-dvb repository from 2.6.16 to at least 2.6.22.
> > > > Ideal for us would even be 2.6.26, but I would understand that this
> > > > is too recent for you. Kernel 2.6.22 is one year and a half old, I
> > > > honestly doubt that people fighting to get their brand new TV
> > > > adapter to work are using anything older. As a matter of fact,
> > > > kernel 2.6.22 is what openSUSE 10.3 has, and this is the oldest
> > > > openSUSE product that is still maintained.
> > > >
> > > > I understand and respect your will to let a large range of users
> > > > build the v4l-dvb repository, but at some point the cost for
> > > > developers seems to be too high, so there's a balance to be found
> > > > between users and developers. At the moment the balance isn't right
> > > > IMHO.
> > >
> > > In my case, I use RHEL 5.3 that comes with 2.6.18. I need at least to
> > > have compatibility until this version, otherwise it will be harder to
> > > me to test things, since most of the time I need to run RHEL 5
> > > kernel.
> > >
> > > I know that other developers also use RHEL 5 on their environments.
> >
> > Why should we have ugly and time consuming workarounds in our
> > repository that hamper progress just to allow you to run RHEL 5? I'm
> > sorry, that's no reason at all. I very much doubt other subsystem
> > maintainers are stuck on 2.6.18.
>
> The role idea of having compatibility code is to allow people to test
> with distro kernels. If we decide do exclude one of the major distro, I
> don't see why not dropping support for the other distros and older
> kernels. For sure removing all backports will make developers happy, but
> this will reduce the amount of users that can help with the development,
> testing the drivers and providing us patches.

99% (if not 100%) of that comes from the desktop area. We are bending over 
backwards for the mythical enterprise user who cannot upgrade, must have 
the latest drivers and wants it all for free. In the meantime we have 
crummy code in the kernel only to support this mythical user, and new 
developers starting to work with v4l are confused by the weird way i2c 
drivers are setup.

> It would be much more easy to me to just drop all -hg trees with all
> backport and out-of-tree compilation and stuck with my -git trees, just
> like other sybsystem maintainers do, but I _do_ think that our community
> will suffer a lot with this. So, let's keep supporting at least the
> latest kernel version used by the major distros. So, for now, we should
> still keep support for 2.6.18.

It's not our job. It's the job of the distro companies to maintain their 
code and drivers and backport newer ones if needed. That's what they are 
paid for. I'm not paid for that, yet I still have to spend valuable time 
doing this shit (excuse the language).

If people are so keen on it, then let them pay me.

> > And anyway, there is no way you can do proper testing against the new
> > i2c API on that old kernel. The loading and probing of i2c modules is
> > quite different, so that's never representative of what kernels >=
> > 2.6.22 do.
>
> I can assure you that I2C with v4l/dvb drivers work fine with 2.6.18. I
> use here with several drivers (uvc, bttv, saa7134, em28xx, ...).
>
> As a normal user, I use skype regularly the latest uvc driver + 2.6.18 on
> RHEL5.
>
> Of course, while developing, we should always test the drivers against
> the latest upstream tree, but this don't reduce the value of allowing
> normal users to use the latest drivers with their systems.

Normal v4l users use a desktop PC and can easily upgrade. Enterprise users 
locked to an ancient kernel AND using v4l-dvb are NOT normal users. I've 
just looked it up and apparently RHEL 6 isn't planned for another year. By 
that time we're on 2.6.32/33 and maintaining compatibility for a whopping 
15 kernels. Doesn't that strike you as ridiculous?

I might be wrong, but aren't you using RHEL 5 because you work for redhat 
these days? Not a typical user at all.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Minimum kernel version supported by v4l-dvb

[Uri Shkolnik]

--- On Wed, 2/18/09, Hans Verkuil <hverkuil@xs4all.nl> wrote:

> From: Hans Verkuil <hverkuil@xs4all.nl>
> Subject: Re: Minimum kernel version supported by v4l-dvb
> To: "Mauro Carvalho Chehab" <mchehab@infradead.org>
> Cc: "Jean Delvare" <khali@linux-fr.org>, linux-media@vger.kernel.org
> Date: Wednesday, February 18, 2009, 9:36 AM
> On Wednesday 18 February 2009 03:08:15 Mauro Carvalho Chehab
> wrote:
> > On Wed, 18 Feb 2009 01:18:37 +0100
> >
> > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > On Wednesday 18 February 2009 01:08:23 Mauro
> Carvalho Chehab wrote:
> > > > On Tue, 17 Feb 2009 14:23:27 +0100
> > > >
> > > > Jean Delvare <khali@linux-fr.org>
> wrote:
> > > > > Hi Mauro,
> > > > >
> > > > > These days I am helping Hans Verkuil
> convert the last users of the
> > > > > legacy i2c device driver binding model
> to the new, standard binding
> > > > > model. It turns out to be a very
> complex task because the v4l-dvb
> > > > > repository is supposed to still support
> kernels as old as 2.6.16,
> > > > > while the initial support for the new
> i2c binding model was added
> > > > > in kernel 2.6.22 (and even that is
> somewhat different from what is
> > > > > upstream now.) This forces us to add
> quirks all around the place,
> > > > > which will surely result in bugs
> because the code becomes hard to
> > > > > read, understand and maintain.
> > > > >
> > > > > In fact, without this need for
> backwards compatibility, I would
> > > > > probably have been able to convert most
> of the drivers myself,
> > > > > without Hans' help, and this would
> already be all done. But as
> > > > > things stand today, he has to do most
> of the work, and our progress
> > > > > is slow.
> > > > >
> > > > > So I would like you to consider
> changing the minimum kernel version
> > > > > supported by the v4l-dvb repository
> from 2.6.16 to at least 2.6.22.
> > > > > Ideal for us would even be 2.6.26, but
> I would understand that this
> > > > > is too recent for you. Kernel 2.6.22 is
> one year and a half old, I
> > > > > honestly doubt that people fighting to
> get their brand new TV
> > > > > adapter to work are using anything
> older. As a matter of fact,
> > > > > kernel 2.6.22 is what openSUSE 10.3
> has, and this is the oldest
> > > > > openSUSE product that is still
> maintained.
> > > > >
> > > > > I understand and respect your will to
> let a large range of users
> > > > > build the v4l-dvb repository, but at
> some point the cost for
> > > > > developers seems to be too high, so
> there's a balance to be found
> > > > > between users and developers. At the
> moment the balance isn't right
> > > > > IMHO.
> > > >
> > > > In my case, I use RHEL 5.3 that comes with
> 2.6.18. I need at least to
> > > > have compatibility until this version,
> otherwise it will be harder to
> > > > me to test things, since most of the time I
> need to run RHEL 5
> > > > kernel.
> > > >
> > > > I know that other developers also use RHEL 5
> on their environments.
> > >
> > > Why should we have ugly and time consuming
> workarounds in our
> > > repository that hamper progress just to allow you
> to run RHEL 5? I'm
> > > sorry, that's no reason at all. I very much
> doubt other subsystem
> > > maintainers are stuck on 2.6.18.
> >
> > The role idea of having compatibility code is to allow
> people to test
> > with distro kernels. If we decide do exclude one of
> the major distro, I
> > don't see why not dropping support for the other
> distros and older
> > kernels. For sure removing all backports will make
> developers happy, but
> > this will reduce the amount of users that can help
> with the development,
> > testing the drivers and providing us patches.
> 
> 99% (if not 100%) of that comes from the desktop area. We
> are bending over 
> backwards for the mythical enterprise user who cannot
> upgrade, must have 
> the latest drivers and wants it all for free. In the
> meantime we have 
> crummy code in the kernel only to support this mythical
> user, and new 
> developers starting to work with v4l are confused by the
> weird way i2c 
> drivers are setup.
> 
> > It would be much more easy to me to just drop all -hg
> trees with all
> > backport and out-of-tree compilation and stuck with my
> -git trees, just
> > like other sybsystem maintainers do, but I _do_ think
> that our community
> > will suffer a lot with this. So, let's keep
> supporting at least the
> > latest kernel version used by the major distros. So,
> for now, we should
> > still keep support for 2.6.18.
> 
> It's not our job. It's the job of the distro
> companies to maintain their 
> code and drivers and backport newer ones if needed.
> That's what they are 
> paid for. I'm not paid for that, yet I still have to
> spend valuable time 
> doing this shit (excuse the language).
> 
> If people are so keen on it, then let them pay me.
> 
> > > And anyway, there is no way you can do proper
> testing against the new
> > > i2c API on that old kernel. The loading and
> probing of i2c modules is
> > > quite different, so that's never
> representative of what kernels >=
> > > 2.6.22 do.
> >
> > I can assure you that I2C with v4l/dvb drivers work
> fine with 2.6.18. I
> > use here with several drivers (uvc, bttv, saa7134,
> em28xx, ...).
> >
> > As a normal user, I use skype regularly the latest uvc
> driver + 2.6.18 on
> > RHEL5.
> >
> > Of course, while developing, we should always test the
> drivers against
> > the latest upstream tree, but this don't reduce
> the value of allowing
> > normal users to use the latest drivers with their
> systems.
> 
> Normal v4l users use a desktop PC and can easily upgrade.
> Enterprise users 
> locked to an ancient kernel AND using v4l-dvb are NOT
> normal users. I've 
> just looked it up and apparently RHEL 6 isn't planned
> for another year. By 
> that time we're on 2.6.32/33 and maintaining
> compatibility for a whopping 
> 15 kernels. Doesn't that strike you as ridiculous?
> 
> I might be wrong, but aren't you using RHEL 5 because
> you work for redhat 
> these days? Not a typical user at all.
> 
> Regards,
> 
> 	Hans
> 
> -- 
> Hans Verkuil - video4linux developer - sponsored by
> TANDBERG


Hi,

I strongly oppose the idea to suppress old kernel versions' support.
People here discuss Linux as "This (PC) distro" and other "Desktop" flavor.
But, you must look at the global Linux market. Multiple embedded devices use Linux OS. The embedded Linux "market share" is something to argue about, some say that it about 25%, while other say its about 40%. The true numbers are unknown, since those devices can not be counted easily (like when access to any web-server), and the commercial companies that manufacture those devices neglect to publish numbers (anything between 5 to 7 digits number per device type are legit as any other). 
The problem is, that the BSPs (board support package to all PC guys here) for those devices are frozen, and hence the kernel version too. 
I know devices that still use 2.6.10 (MontaVista) and other old version...

So, older version support is essential for those devices.


Uri Shkolnik




      

Re: Minimum kernel version supported by v4l-dvb

[Hans Verkuil]

>
>
>
> --- On Wed, 2/18/09, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
>> From: Hans Verkuil <hverkuil@xs4all.nl>
>> Subject: Re: Minimum kernel version supported by v4l-dvb
>> To: "Mauro Carvalho Chehab" <mchehab@infradead.org>
>> Cc: "Jean Delvare" <khali@linux-fr.org>, linux-media@vger.kernel.org
>> Date: Wednesday, February 18, 2009, 9:36 AM
>> On Wednesday 18 February 2009 03:08:15 Mauro Carvalho Chehab
>> wrote:
>> > On Wed, 18 Feb 2009 01:18:37 +0100
>> >
>> > Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> > > On Wednesday 18 February 2009 01:08:23 Mauro
>> Carvalho Chehab wrote:
>> > > > On Tue, 17 Feb 2009 14:23:27 +0100
>> > > >
>> > > > Jean Delvare <khali@linux-fr.org>
>> wrote:
>> > > > > Hi Mauro,
>> > > > >
>> > > > > These days I am helping Hans Verkuil
>> convert the last users of the
>> > > > > legacy i2c device driver binding model
>> to the new, standard binding
>> > > > > model. It turns out to be a very
>> complex task because the v4l-dvb
>> > > > > repository is supposed to still support
>> kernels as old as 2.6.16,
>> > > > > while the initial support for the new
>> i2c binding model was added
>> > > > > in kernel 2.6.22 (and even that is
>> somewhat different from what is
>> > > > > upstream now.) This forces us to add
>> quirks all around the place,
>> > > > > which will surely result in bugs
>> because the code becomes hard to
>> > > > > read, understand and maintain.
>> > > > >
>> > > > > In fact, without this need for
>> backwards compatibility, I would
>> > > > > probably have been able to convert most
>> of the drivers myself,
>> > > > > without Hans' help, and this would
>> already be all done. But as
>> > > > > things stand today, he has to do most
>> of the work, and our progress
>> > > > > is slow.
>> > > > >
>> > > > > So I would like you to consider
>> changing the minimum kernel version
>> > > > > supported by the v4l-dvb repository
>> from 2.6.16 to at least 2.6.22.
>> > > > > Ideal for us would even be 2.6.26, but
>> I would understand that this
>> > > > > is too recent for you. Kernel 2.6.22 is
>> one year and a half old, I
>> > > > > honestly doubt that people fighting to
>> get their brand new TV
>> > > > > adapter to work are using anything
>> older. As a matter of fact,
>> > > > > kernel 2.6.22 is what openSUSE 10.3
>> has, and this is the oldest
>> > > > > openSUSE product that is still
>> maintained.
>> > > > >
>> > > > > I understand and respect your will to
>> let a large range of users
>> > > > > build the v4l-dvb repository, but at
>> some point the cost for
>> > > > > developers seems to be too high, so
>> there's a balance to be found
>> > > > > between users and developers. At the
>> moment the balance isn't right
>> > > > > IMHO.
>> > > >
>> > > > In my case, I use RHEL 5.3 that comes with
>> 2.6.18. I need at least to
>> > > > have compatibility until this version,
>> otherwise it will be harder to
>> > > > me to test things, since most of the time I
>> need to run RHEL 5
>> > > > kernel.
>> > > >
>> > > > I know that other developers also use RHEL 5
>> on their environments.
>> > >
>> > > Why should we have ugly and time consuming
>> workarounds in our
>> > > repository that hamper progress just to allow you
>> to run RHEL 5? I'm
>> > > sorry, that's no reason at all. I very much
>> doubt other subsystem
>> > > maintainers are stuck on 2.6.18.
>> >
>> > The role idea of having compatibility code is to allow
>> people to test
>> > with distro kernels. If we decide do exclude one of
>> the major distro, I
>> > don't see why not dropping support for the other
>> distros and older
>> > kernels. For sure removing all backports will make
>> developers happy, but
>> > this will reduce the amount of users that can help
>> with the development,
>> > testing the drivers and providing us patches.
>>
>> 99% (if not 100%) of that comes from the desktop area. We
>> are bending over
>> backwards for the mythical enterprise user who cannot
>> upgrade, must have
>> the latest drivers and wants it all for free. In the
>> meantime we have
>> crummy code in the kernel only to support this mythical
>> user, and new
>> developers starting to work with v4l are confused by the
>> weird way i2c
>> drivers are setup.
>>
>> > It would be much more easy to me to just drop all -hg
>> trees with all
>> > backport and out-of-tree compilation and stuck with my
>> -git trees, just
>> > like other sybsystem maintainers do, but I _do_ think
>> that our community
>> > will suffer a lot with this. So, let's keep
>> supporting at least the
>> > latest kernel version used by the major distros. So,
>> for now, we should
>> > still keep support for 2.6.18.
>>
>> It's not our job. It's the job of the distro
>> companies to maintain their
>> code and drivers and backport newer ones if needed.
>> That's what they are
>> paid for. I'm not paid for that, yet I still have to
>> spend valuable time
>> doing this shit (excuse the language).
>>
>> If people are so keen on it, then let them pay me.
>>
>> > > And anyway, there is no way you can do proper
>> testing against the new
>> > > i2c API on that old kernel. The loading and
>> probing of i2c modules is
>> > > quite different, so that's never
>> representative of what kernels >=
>> > > 2.6.22 do.
>> >
>> > I can assure you that I2C with v4l/dvb drivers work
>> fine with 2.6.18. I
>> > use here with several drivers (uvc, bttv, saa7134,
>> em28xx, ...).
>> >
>> > As a normal user, I use skype regularly the latest uvc
>> driver + 2.6.18 on
>> > RHEL5.
>> >
>> > Of course, while developing, we should always test the
>> drivers against
>> > the latest upstream tree, but this don't reduce
>> the value of allowing
>> > normal users to use the latest drivers with their
>> systems.
>>
>> Normal v4l users use a desktop PC and can easily upgrade.
>> Enterprise users
>> locked to an ancient kernel AND using v4l-dvb are NOT
>> normal users. I've
>> just looked it up and apparently RHEL 6 isn't planned
>> for another year. By
>> that time we're on 2.6.32/33 and maintaining
>> compatibility for a whopping
>> 15 kernels. Doesn't that strike you as ridiculous?
>>
>> I might be wrong, but aren't you using RHEL 5 because
>> you work for redhat
>> these days? Not a typical user at all.
>>
>> Regards,
>>
>> 	Hans
>>
>> --
>> Hans Verkuil - video4linux developer - sponsored by
>> TANDBERG
>
>
> Hi,
>
> I strongly oppose the idea to suppress old kernel versions' support.
> People here discuss Linux as "This (PC) distro" and other "Desktop"
> flavor.
> But, you must look at the global Linux market. Multiple embedded devices
> use Linux OS. The embedded Linux "market share" is something to argue
> about, some say that it about 25%, while other say its about 40%. The true
> numbers are unknown, since those devices can not be counted easily (like
> when access to any web-server), and the commercial companies that
> manufacture those devices neglect to publish numbers (anything between 5
> to 7 digits number per device type are legit as any other).
> The problem is, that the BSPs (board support package to all PC guys here)
> for those devices are frozen, and hence the kernel version too.
> I know devices that still use 2.6.10 (MontaVista) and other old version...
>
> So, older version support is essential for those devices.

Not at all. I work with embedded systems and what happens is that you
effectively take a kernel snapshot for your device and stick to that.
You're not using v4l-dvb, but you might backport important fixes on
occasion.

Again, it's not our job. The linux model is to get your drivers into the
kernel, then let distros take care of the rest, which includes backporting
if needed to older kernels. We are doing the work that distros should be
doing. A few years ago I moved ivtv to v4l-dvb and the kernel with the
express purpose to be finally free of keeping it backwards compatible with
older kernels. Now I find myself doing the same AGAIN.

And you are talking about that mythical user that needs it. I've yet to
SEE that user here and telling me that it is essential to their product.

PROVE to me that it is really necessary and really our job, and esp. my
job, since *I'm* the one keeping the backwards compatibility for i2c
modules alive. All I hear is 'there might be', 'I know some company', 'I
heard'.

Right now there is crappy code in the kernel whose only purpose is to
facilitate support for old kernels. That's actually against the kernel
policy.

One alternative is it create a separate repository just before the compat
code is removed, and merge important fixes for drivers in there. That
should tide us over until RHEL 6 is released.

Which also raises the other question: what criterium is there anyway to
decide what is the oldest kernel to support? RHEL 5 will no doubt be used
for 1-2 years after RHEL 6 is release, do we still keep support for that?
Old kernels will be used for a long time in embedded systems, do we still
keep support for that too?

The only reasonable criterium I see is technical: when you start to
introduce cruft into the kernel just to support older kernels, then it is
time to cut off support to those kernels.

Regards,

          Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Minimum kernel version supported by v4l-dvb

[Mauro Carvalho Chehab]

On Wed, 18 Feb 2009 09:55:53 +0100 (CET)
"Hans Verkuil" <hverkuil@xs4all.nl> wrote:

> Not at all. I work with embedded systems and what happens is that you
> effectively take a kernel snapshot for your device and stick to that.
> You're not using v4l-dvb, but you might backport important fixes on
> occasion.
> 
> Again, it's not our job. The linux model is to get your drivers into the
> kernel, then let distros take care of the rest, which includes backporting
> if needed to older kernels. We are doing the work that distros should be
> doing. A few years ago I moved ivtv to v4l-dvb and the kernel with the
> express purpose to be finally free of keeping it backwards compatible with
> older kernels. Now I find myself doing the same AGAIN.
> 
> And you are talking about that mythical user that needs it. I've yet to
> SEE that user here and telling me that it is essential to their product.
> 
> PROVE to me that it is really necessary and really our job, and esp. my
> job, since *I'm* the one keeping the backwards compatibility for i2c
> modules alive. All I hear is 'there might be', 'I know some company', 'I
> heard'.
> 
> Right now there is crappy code in the kernel whose only purpose is to
> facilitate support for old kernels. That's actually against the kernel
> policy.
> 
> One alternative is it create a separate repository just before the compat
> code is removed, and merge important fixes for drivers in there. That
> should tide us over until RHEL 6 is released.
> 
> Which also raises the other question: what criterium is there anyway to
> decide what is the oldest kernel to support? RHEL 5 will no doubt be used
> for 1-2 years after RHEL 6 is release, do we still keep support for that?
> Old kernels will be used for a long time in embedded systems, do we still
> keep support for that too?

Hans, I'm doing backport since 2005. So, you are not the only one that are
doing backports. On V4L, this started ever since. In the case of DVB, we
started backport on 2006. Before that, they use to support only the latest
kernel version.

If you get a snapshot of our tree of about 6 months to one year ago, we had
even support for linux-2.4 I2C (and yes, this works - I have a tree here for
vivi and bttv drivers based on that i2c support, working with 2.4).

In the past, our criteria were simply to support all 2.6 versions and the
latest 2.4 versions. Sometime after having the last 2.4 distro moving their
stable repo to 2.6, we decided to drop 2.4, because we got no complains to keep
2.4 on that time.

Maybe the current solution for i2c backport is not the better one, and we
need to use another approach. If the current i2c backport is interfering on the
development, then maybe we need to re-think about the backport implementation.
The backport shouldn't affect the upstream. It were never affected until the
recent i2c backport. Even the 2.4 i2c backport didn't interfere upstream, even
having a completely different implementation on 2.4.

> The only reasonable criterium I see is technical: when you start to
> introduce cruft into the kernel just to support older kernels, then it is
> time to cut off support to those kernels.

The criteria for backport is not technical. It is all about offering a version
that testers with standard distros can use it, without needing to use the
latest -rc kernel.

I'm fine to drop support to unused kernels, but the hole idea to have backport
is to allow an easy usage of the newer drivers by users with their environment.
If we start removing such code, due to any other criteria different than having
support for kernels that people are still using on their desktop and enterprise
environments, then it is time to forget about -hg and use -git instead,
supporting only the latest tip kernel, just like almost all other maintainers
do.

While we are stick on have backport, we need at least to support the latest
desktop and enterprise kernel versions of the major distros.

So, it is a matter of deciding what we want:
	keep our current criteria of offering backport kernels that include
	at least the kernel version used on the major desktop and enterprise
	kernel distros
OR
	just use -git and drop all backport code.

Both solutions work for me, although I prefer to keep backport, even having more trouble[1]. 

Anything else and we will enter of a grey area that will likely go nowhere.

[1] Side note: i2c is not the only subsystem whose changes affect our tree. I
have on my TODO list a backport on dvbnet, due to some net changes at 2.6.29-rc:

$ diffstat /tmp/diff
 dvb_net.c |   57 ++++++++++++++++++++++++++++-----------------------------
 1 file changed, 28 insertions(+), 29 deletions(-)

In this case, several data that used to be stored on one struct moved to another.
So, if applied as-is, it will just break support for all kernels lower
than 2.6.29 on all drivers that supports DVB. On the other hand, our -hg
trees don't work with 2.6.29-rc.

Cheers,
Mauro

Re: Minimum kernel version supported by v4l-dvb

[Hans Verkuil]

Hi Mauro,

> On Wed, 18 Feb 2009 09:55:53 +0100 (CET)
> "Hans Verkuil" <hverkuil@xs4all.nl> wrote:
>
>> Not at all. I work with embedded systems and what happens is that you
>> effectively take a kernel snapshot for your device and stick to that.
>> You're not using v4l-dvb, but you might backport important fixes on
>> occasion.
>>
>> Again, it's not our job. The linux model is to get your drivers into the
>> kernel, then let distros take care of the rest, which includes
>> backporting
>> if needed to older kernels. We are doing the work that distros should be
>> doing. A few years ago I moved ivtv to v4l-dvb and the kernel with the
>> express purpose to be finally free of keeping it backwards compatible
>> with
>> older kernels. Now I find myself doing the same AGAIN.
>>
>> And you are talking about that mythical user that needs it. I've yet to
>> SEE that user here and telling me that it is essential to their product.
>>
>> PROVE to me that it is really necessary and really our job, and esp. my
>> job, since *I'm* the one keeping the backwards compatibility for i2c
>> modules alive. All I hear is 'there might be', 'I know some company', 'I
>> heard'.
>>
>> Right now there is crappy code in the kernel whose only purpose is to
>> facilitate support for old kernels. That's actually against the kernel
>> policy.
>>
>> One alternative is it create a separate repository just before the
>> compat
>> code is removed, and merge important fixes for drivers in there. That
>> should tide us over until RHEL 6 is released.
>>
>> Which also raises the other question: what criterium is there anyway to
>> decide what is the oldest kernel to support? RHEL 5 will no doubt be
>> used
>> for 1-2 years after RHEL 6 is release, do we still keep support for
>> that?
>> Old kernels will be used for a long time in embedded systems, do we
>> still
>> keep support for that too?
>
> Hans, I'm doing backport since 2005. So, you are not the only one that are
> doing backports. On V4L, this started ever since. In the case of DVB, we
> started backport on 2006. Before that, they use to support only the latest
> kernel version.

I never said otherwise. All the more reason to abandon this model. I
honestly think we should re-evaluate our development process. Whenever new
developers come in (and a lot are coming in from the embedded space) their
first question is: where is your git tree? There is a reason why this
model is being adopted widely.

> If you get a snapshot of our tree of about 6 months to one year ago, we
> had
> even support for linux-2.4 I2C (and yes, this works - I have a tree here
> for
> vivi and bttv drivers based on that i2c support, working with 2.4).
>
> In the past, our criteria were simply to support all 2.6 versions and the
> latest 2.4 versions. Sometime after having the last 2.4 distro moving
> their
> stable repo to 2.6, we decided to drop 2.4, because we got no complains to
> keep
> 2.4 on that time.
>
> Maybe the current solution for i2c backport is not the better one, and we
> need to use another approach. If the current i2c backport is interfering
> on the
> development, then maybe we need to re-think about the backport
> implementation.
> The backport shouldn't affect the upstream. It were never affected until
> the
> recent i2c backport. Even the 2.4 i2c backport didn't interfere upstream,
> even
> having a completely different implementation on 2.4.
>
>> The only reasonable criterium I see is technical: when you start to
>> introduce cruft into the kernel just to support older kernels, then it
>> is
>> time to cut off support to those kernels.
>
> The criteria for backport is not technical. It is all about offering a
> version
> that testers with standard distros can use it, without needing to use the
> latest -rc kernel.
>
> I'm fine to drop support to unused kernels, but the hole idea to have
> backport
> is to allow an easy usage of the newer drivers by users with their
> environment.
> If we start removing such code, due to any other criteria different than
> having
> support for kernels that people are still using on their desktop and
> enterprise
> environments, then it is time to forget about -hg and use -git instead,
> supporting only the latest tip kernel, just like almost all other
> maintainers
> do.

Yes please!

> While we are stick on have backport, we need at least to support the
> latest
> desktop and enterprise kernel versions of the major distros.
>
> So, it is a matter of deciding what we want:
> 	keep our current criteria of offering backport kernels that include
> 	at least the kernel version used on the major desktop and enterprise
> 	kernel distros
> OR
> 	just use -git and drop all backport code.
>
> Both solutions work for me, although I prefer to keep backport, even
> having more trouble[1].
>
> Anything else and we will enter of a grey area that will likely go
> nowhere.
>
> [1] Side note: i2c is not the only subsystem whose changes affect our
> tree. I
> have on my TODO list a backport on dvbnet, due to some net changes at
> 2.6.29-rc:
>
> $ diffstat /tmp/diff
>  dvb_net.c |   57
> ++++++++++++++++++++++++++++-----------------------------
>  1 file changed, 28 insertions(+), 29 deletions(-)
>
> In this case, several data that used to be stored on one struct moved to
> another.
> So, if applied as-is, it will just break support for all kernels lower
> than 2.6.29 on all drivers that supports DVB. On the other hand, our -hg
> trees don't work with 2.6.29-rc.

This really proves my point, I think: it's not our business to do this
sort of work. Our model is outdated. Consider also that several years ago
v4l-dvb was considerably smaller and easier to maintain. It has grown
substantially with more devices coming in all the time. The old model IMHO
no longer scales to this rate of development.

Regards,

        Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Minimum kernel version supported by v4l-dvb

[Mauro Carvalho Chehab]

On Wed, 18 Feb 2009 11:54:30 +0100 (CET)
"Hans Verkuil" <hverkuil@xs4all.nl> wrote:

> Hi Mauro,
> 
> > On Wed, 18 Feb 2009 09:55:53 +0100 (CET)
> > "Hans Verkuil" <hverkuil@xs4all.nl> wrote:
> >
> >> Not at all. I work with embedded systems and what happens is that you
> >> effectively take a kernel snapshot for your device and stick to that.
> >> You're not using v4l-dvb, but you might backport important fixes on
> >> occasion.
> >>
> >> Again, it's not our job. The linux model is to get your drivers into the
> >> kernel, then let distros take care of the rest, which includes
> >> backporting
> >> if needed to older kernels. We are doing the work that distros should be
> >> doing. A few years ago I moved ivtv to v4l-dvb and the kernel with the
> >> express purpose to be finally free of keeping it backwards compatible
> >> with
> >> older kernels. Now I find myself doing the same AGAIN.
> >>
> >> And you are talking about that mythical user that needs it. I've yet to
> >> SEE that user here and telling me that it is essential to their product.
> >>
> >> PROVE to me that it is really necessary and really our job, and esp. my
> >> job, since *I'm* the one keeping the backwards compatibility for i2c
> >> modules alive. All I hear is 'there might be', 'I know some company', 'I
> >> heard'.
> >>
> >> Right now there is crappy code in the kernel whose only purpose is to
> >> facilitate support for old kernels. That's actually against the kernel
> >> policy.
> >>
> >> One alternative is it create a separate repository just before the
> >> compat
> >> code is removed, and merge important fixes for drivers in there. That
> >> should tide us over until RHEL 6 is released.
> >>
> >> Which also raises the other question: what criterium is there anyway to
> >> decide what is the oldest kernel to support? RHEL 5 will no doubt be
> >> used
> >> for 1-2 years after RHEL 6 is release, do we still keep support for
> >> that?
> >> Old kernels will be used for a long time in embedded systems, do we
> >> still
> >> keep support for that too?
> >
> > Hans, I'm doing backport since 2005. So, you are not the only one that are
> > doing backports. On V4L, this started ever since. In the case of DVB, we
> > started backport on 2006. Before that, they use to support only the latest
> > kernel version.
> 
> I never said otherwise. All the more reason to abandon this model. I
> honestly think we should re-evaluate our development process. Whenever new
> developers come in (and a lot are coming in from the embedded space) their
> first question is: where is your git tree? There is a reason why this
> model is being adopted widely.
> 
> > If you get a snapshot of our tree of about 6 months to one year ago, we
> > had
> > even support for linux-2.4 I2C (and yes, this works - I have a tree here
> > for
> > vivi and bttv drivers based on that i2c support, working with 2.4).
> >
> > In the past, our criteria were simply to support all 2.6 versions and the
> > latest 2.4 versions. Sometime after having the last 2.4 distro moving
> > their
> > stable repo to 2.6, we decided to drop 2.4, because we got no complains to
> > keep
> > 2.4 on that time.
> >
> > Maybe the current solution for i2c backport is not the better one, and we
> > need to use another approach. If the current i2c backport is interfering
> > on the
> > development, then maybe we need to re-think about the backport
> > implementation.
> > The backport shouldn't affect the upstream. It were never affected until
> > the
> > recent i2c backport. Even the 2.4 i2c backport didn't interfere upstream,
> > even
> > having a completely different implementation on 2.4.
> >
> >> The only reasonable criterium I see is technical: when you start to
> >> introduce cruft into the kernel just to support older kernels, then it
> >> is
> >> time to cut off support to those kernels.
> >
> > The criteria for backport is not technical. It is all about offering a
> > version
> > that testers with standard distros can use it, without needing to use the
> > latest -rc kernel.
> >
> > I'm fine to drop support to unused kernels, but the hole idea to have
> > backport
> > is to allow an easy usage of the newer drivers by users with their
> > environment.
> > If we start removing such code, due to any other criteria different than
> > having
> > support for kernels that people are still using on their desktop and
> > enterprise
> > environments, then it is time to forget about -hg and use -git instead,
> > supporting only the latest tip kernel, just like almost all other
> > maintainers
> > do.
> 
> Yes please!
> 
> > While we are stick on have backport, we need at least to support the
> > latest
> > desktop and enterprise kernel versions of the major distros.
> >
> > So, it is a matter of deciding what we want:
> > 	keep our current criteria of offering backport kernels that include
> > 	at least the kernel version used on the major desktop and enterprise
> > 	kernel distros
> > OR
> > 	just use -git and drop all backport code.
> >
> > Both solutions work for me, although I prefer to keep backport, even
> > having more trouble[1].
> >
> > Anything else and we will enter of a grey area that will likely go
> > nowhere.
> >
> > [1] Side note: i2c is not the only subsystem whose changes affect our
> > tree. I
> > have on my TODO list a backport on dvbnet, due to some net changes at
> > 2.6.29-rc:
> >
> > $ diffstat /tmp/diff
> >  dvb_net.c |   57
> > ++++++++++++++++++++++++++++-----------------------------
> >  1 file changed, 28 insertions(+), 29 deletions(-)
> >
> > In this case, several data that used to be stored on one struct moved to
> > another.
> > So, if applied as-is, it will just break support for all kernels lower
> > than 2.6.29 on all drivers that supports DVB. On the other hand, our -hg
> > trees don't work with 2.6.29-rc.
> 
> This really proves my point, I think: it's not our business to do this
> sort of work. Our model is outdated. Consider also that several years ago
> v4l-dvb was considerably smaller and easier to maintain. It has grown
> substantially with more devices coming in all the time. The old model IMHO
> no longer scales to this rate of development.

Ok. Then, please start a RFC thread about this. Let's see the views of the
other community members.

Cheers,
Mauro

Re: Minimum kernel version supported by v4l-dvb

[Jean Delvare]

Hi Mauro,

On Wed, 18 Feb 2009 07:10:41 -0300, Mauro Carvalho Chehab wrote:
> On Wed, 18 Feb 2009 09:55:53 +0100 (CET)
> "Hans Verkuil" <hverkuil@xs4all.nl> wrote:
> 
> > Not at all. I work with embedded systems and what happens is that you
> > effectively take a kernel snapshot for your device and stick to that.
> > You're not using v4l-dvb, but you might backport important fixes on
> > occasion.
> > 
> > Again, it's not our job. The linux model is to get your drivers into the
> > kernel, then let distros take care of the rest, which includes backporting
> > if needed to older kernels. We are doing the work that distros should be
> > doing. A few years ago I moved ivtv to v4l-dvb and the kernel with the
> > express purpose to be finally free of keeping it backwards compatible with
> > older kernels. Now I find myself doing the same AGAIN.
> > 
> > And you are talking about that mythical user that needs it. I've yet to
> > SEE that user here and telling me that it is essential to their product.
> > 
> > PROVE to me that it is really necessary and really our job, and esp. my
> > job, since *I'm* the one keeping the backwards compatibility for i2c
> > modules alive. All I hear is 'there might be', 'I know some company', 'I
> > heard'.
> > 
> > Right now there is crappy code in the kernel whose only purpose is to
> > facilitate support for old kernels. That's actually against the kernel
> > policy.
> > 
> > One alternative is it create a separate repository just before the compat
> > code is removed, and merge important fixes for drivers in there. That
> > should tide us over until RHEL 6 is released.
> > 
> > Which also raises the other question: what criterium is there anyway to
> > decide what is the oldest kernel to support? RHEL 5 will no doubt be used
> > for 1-2 years after RHEL 6 is release, do we still keep support for that?
> > Old kernels will be used for a long time in embedded systems, do we still
> > keep support for that too?
> 
> Hans, I'm doing backport since 2005. So, you are not the only one that are
> doing backports. On V4L, this started ever since. In the case of DVB, we
> started backport on 2006. Before that, they use to support only the latest
> kernel version.
> 
> If you get a snapshot of our tree of about 6 months to one year ago, we had
> even support for linux-2.4 I2C (and yes, this works - I have a tree here for
> vivi and bttv drivers based on that i2c support, working with 2.4).

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.

> In the past, our criteria were simply to support all 2.6 versions and the
> latest 2.4 versions. Sometime after having the last 2.4 distro moving their
> stable repo to 2.6, we decided to drop 2.4, because we got no complains to keep
> 2.4 on that time.
> 
> Maybe the current solution for i2c backport is not the better one, and we
> need to use another approach. If the current i2c backport is interfering on the
> development, then maybe we need to re-think about the backport implementation.
> The backport shouldn't affect the upstream. It were never affected until the
> recent i2c backport. Even the 2.4 i2c backport didn't interfere upstream, even
> having a completely different implementation on 2.4.

Actually, 2.6 kernels up to 2.6.13 had an i2c API very similar to what
2.4 had. The binding model changes we are undergoing now are way more
intrusive than the migration from 2.4 to early 2.6.

> > The only reasonable criterium I see is technical: when you start to
> > introduce cruft into the kernel just to support older kernels, then it is
> > time to cut off support to those kernels.
> 
> The criteria for backport is not technical.

That technical isn't the only criteria, I agree with. But claiming that
technical isn't a criteria at all is plain wrong. This is equivalent to
claiming that development time doesn't cost anything.

>                                       (...) It is all about offering a version
> that testers with standard distros can use it, without needing to use the
> latest -rc kernel.
> 
> I'm fine to drop support to unused kernels, but the hole idea to have backport
> is to allow an easy usage of the newer drivers by users with their environment.
> If we start removing such code, due to any other criteria different than having
> support for kernels that people are still using on their desktop and enterprise
> environments, 

You're aiming at the wrong target, I am afraid. "Enterprise
environments" have _nothing_ to do with upstream development, by
definition. More on that below.

>         (...) then it is time to forget about -hg and use -git instead,
> supporting only the latest tip kernel, just like almost all other maintainers
> do.
> 
> While we are stick on have backport, we need at least to support the latest
> desktop and enterprise kernel versions of the major distros.
> 
> So, it is a matter of deciding what we want:
> 	keep our current criteria of offering backport kernels that include
> 	at least the kernel version used on the major desktop and enterprise
> 	kernel distros

No, not enterprise kernels!

> OR
> 	just use -git and drop all backport code.
> 
> Both solutions work for me, although I prefer to keep backport, even having more trouble[1]. 
> 
> Anything else and we will enter of a grey area that will likely go nowhere.

I am sorry but I don't follow you here. You are basically claiming that
allowing enterprise users (who typically run RHEL or SLED) to build
bleeding-edge drivers off the v4l-dvb repository is very important, but
allowing non-enterprise users and kernel developers (who typically run
Fedora or openSUSE) isn't that important? I believe this is exactly the
other way around.

I am working on L3 support for SLE products, so I know very well what
enterprise customers want, and what they don't. I doubt that RHEL
customers are any different from SLE ones. Enterprise customers don't
give a damn to the v4l-dvb repository. All they know about and want are
packages provided by the vendor, which change as little as possible
(that is, bug fixes only.) Running bleeding-edge, untrusted and
unmaintained drivers is the last thing they want. If they need a driver
for a recent piece of hardware, they open a feature request for the
next service pack, and leave it to the OS vendor to backport the
driver and maintain it for the next 5 years or so.

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.

The actual audience for the v4l-dvb repository is users who do NOT have
a support contract with the OS vendor. That is, home users. These do
not run RHEL and SLE, especially if they have recent hardware, given
how bad hardware support is in enterprise distributions. Home users
will want their hard disk controller, graphics adapter and sound chip
to work before they even consider getting support for their TV adapter
from the v4l-dvb repository. Which means that they will be running a
recent version of Fedora, openSUSE or equivalent.

Now, if you look at the support policy of Fedora and openSUSE, you'll
see that they are maintained for 13 [1] to 24 [2] months. In practice,
the oldest supported Fedora is Fedora 9, featuring kernel 2.6.25, and
the oldest supported openSUSE is openSUSE 10.3, featuring kernel
2.6.22. Which is why I claim that there is no point in supporting
anything older than that. When openSUSE 10.3 goes out of maintenance
(end of 2009), we can even drop support for kernels < 2.6.25.

[1] http://fedoraproject.org/wiki/LifeCycle
[2] http://en.opensuse.org/SUSE_Linux_Lifetime

There is a reason why the Linux market has been segmented into
enterprise distributions and community distributions. Ignoring that
reason and trying to support all distributions with the same upstream
repository simply doesn't work.

So, I don't buy your claim that we should either support old enterprise
kernels or not support any old kernel at all. Just like I don't buy
your claim that the technical aspect shouldn't be taken into account
when deciding what kernels you want to support. I think we have to be
pragmatic here. We want to support kernels which users really care
about (and these are the ones in maintained popular non-enterprise
distributions) and which don't cost too much to support from a
technical point of view.

Now, if you think that giving up the hg tree and only supporting Linus'
latest kernel is the way to go, I'm not going to prevent you from going
down that road. As a kernel developer, that would make me very happy.
But I remember that the hg tree is there to help users test the newest
developments without running a bleeding-edge kernel, and that certainly
makes some sense.

Thanks,
-- 
Jean Delvare

Re: Minimum kernel version supported by v4l-dvb

[hermann pitton]

Hi,

Am Mittwoch, den 18.02.2009, 14:01 +0100 schrieb Jean Delvare:
> Hi Mauro,
> 
> On Wed, 18 Feb 2009 07:10:41 -0300, Mauro Carvalho Chehab wrote:
> > On Wed, 18 Feb 2009 09:55:53 +0100 (CET)
> > "Hans Verkuil" <hverkuil@xs4all.nl> wrote:
> > 
> > > Not at all. I work with embedded systems and what happens is that you
> > > effectively take a kernel snapshot for your device and stick to that.
> > > You're not using v4l-dvb, but you might backport important fixes on
> > > occasion.
> > > 
> > > Again, it's not our job. The linux model is to get your drivers into the
> > > kernel, then let distros take care of the rest, which includes backporting
> > > if needed to older kernels. We are doing the work that distros should be
> > > doing. A few years ago I moved ivtv to v4l-dvb and the kernel with the
> > > express purpose to be finally free of keeping it backwards compatible with
> > > older kernels. Now I find myself doing the same AGAIN.
> > > 
> > > And you are talking about that mythical user that needs it. I've yet to
> > > SEE that user here and telling me that it is essential to their product.
> > > 
> > > PROVE to me that it is really necessary and really our job, and esp. my
> > > job, since *I'm* the one keeping the backwards compatibility for i2c
> > > modules alive. All I hear is 'there might be', 'I know some company', 'I
> > > heard'.
> > > 
> > > Right now there is crappy code in the kernel whose only purpose is to
> > > facilitate support for old kernels. That's actually against the kernel
> > > policy.
> > > 
> > > One alternative is it create a separate repository just before the compat
> > > code is removed, and merge important fixes for drivers in there. That
> > > should tide us over until RHEL 6 is released.
> > > 
> > > Which also raises the other question: what criterium is there anyway to
> > > decide what is the oldest kernel to support? RHEL 5 will no doubt be used
> > > for 1-2 years after RHEL 6 is release, do we still keep support for that?
> > > Old kernels will be used for a long time in embedded systems, do we still
> > > keep support for that too?
> > 
> > Hans, I'm doing backport since 2005. So, you are not the only one that are
> > doing backports. On V4L, this started ever since. In the case of DVB, we
> > started backport on 2006. Before that, they use to support only the latest
> > kernel version.
> > 
> > If you get a snapshot of our tree of about 6 months to one year ago, we had
> > even support for linux-2.4 I2C (and yes, this works - I have a tree here for
> > vivi and bttv drivers based on that i2c support, working with 2.4).
> 
> 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.
> 
> > In the past, our criteria were simply to support all 2.6 versions and the
> > latest 2.4 versions. Sometime after having the last 2.4 distro moving their
> > stable repo to 2.6, we decided to drop 2.4, because we got no complains to keep
> > 2.4 on that time.
> > 
> > Maybe the current solution for i2c backport is not the better one, and we
> > need to use another approach. If the current i2c backport is interfering on the
> > development, then maybe we need to re-think about the backport implementation.
> > The backport shouldn't affect the upstream. It were never affected until the
> > recent i2c backport. Even the 2.4 i2c backport didn't interfere upstream, even
> > having a completely different implementation on 2.4.
> 
> Actually, 2.6 kernels up to 2.6.13 had an i2c API very similar to what
> 2.4 had. The binding model changes we are undergoing now are way more
> intrusive than the migration from 2.4 to early 2.6.
> 
> > > The only reasonable criterium I see is technical: when you start to
> > > introduce cruft into the kernel just to support older kernels, then it is
> > > time to cut off support to those kernels.
> > 
> > The criteria for backport is not technical.
> 
> That technical isn't the only criteria, I agree with. But claiming that
> technical isn't a criteria at all is plain wrong. This is equivalent to
> claiming that development time doesn't cost anything.
> 
> >                                       (...) It is all about offering a version
> > that testers with standard distros can use it, without needing to use the
> > latest -rc kernel.
> > 
> > I'm fine to drop support to unused kernels, but the hole idea to have backport
> > is to allow an easy usage of the newer drivers by users with their environment.
> > If we start removing such code, due to any other criteria different than having
> > support for kernels that people are still using on their desktop and enterprise
> > environments, 
> 
> You're aiming at the wrong target, I am afraid. "Enterprise
> environments" have _nothing_ to do with upstream development, by
> definition. More on that below.
> 
> >         (...) then it is time to forget about -hg and use -git instead,
> > supporting only the latest tip kernel, just like almost all other maintainers
> > do.
> > 
> > While we are stick on have backport, we need at least to support the latest
> > desktop and enterprise kernel versions of the major distros.
> > 
> > So, it is a matter of deciding what we want:
> > 	keep our current criteria of offering backport kernels that include
> > 	at least the kernel version used on the major desktop and enterprise
> > 	kernel distros
> 
> No, not enterprise kernels!
> 
> > OR
> > 	just use -git and drop all backport code.
> > 
> > Both solutions work for me, although I prefer to keep backport, even having more trouble[1]. 
> > 
> > Anything else and we will enter of a grey area that will likely go nowhere.
> 
> I am sorry but I don't follow you here. You are basically claiming that
> allowing enterprise users (who typically run RHEL or SLED) to build
> bleeding-edge drivers off the v4l-dvb repository is very important, but
> allowing non-enterprise users and kernel developers (who typically run
> Fedora or openSUSE) isn't that important? I believe this is exactly the
> other way around.
> 
> I am working on L3 support for SLE products, so I know very well what
> enterprise customers want, and what they don't. I doubt that RHEL
> customers are any different from SLE ones. Enterprise customers don't
> give a damn to the v4l-dvb repository. All they know about and want are
> packages provided by the vendor, which change as little as possible
> (that is, bug fixes only.) Running bleeding-edge, untrusted and
> unmaintained drivers is the last thing they want. If they need a driver
> for a recent piece of hardware, they open a feature request for the
> next service pack, and leave it to the OS vendor to backport the
> driver and maintain it for the next 5 years or so.
> 
> 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.
> 
> The actual audience for the v4l-dvb repository is users who do NOT have
> a support contract with the OS vendor. That is, home users. These do
> not run RHEL and SLE, especially if they have recent hardware, given
> how bad hardware support is in enterprise distributions. Home users
> will want their hard disk controller, graphics adapter and sound chip
> to work before they even consider getting support for their TV adapter
> from the v4l-dvb repository. Which means that they will be running a
> recent version of Fedora, openSUSE or equivalent.
> 
> Now, if you look at the support policy of Fedora and openSUSE, you'll
> see that they are maintained for 13 [1] to 24 [2] months. In practice,
> the oldest supported Fedora is Fedora 9, featuring kernel 2.6.25, and
> the oldest supported openSUSE is openSUSE 10.3, featuring kernel
> 2.6.22. Which is why I claim that there is no point in supporting
> anything older than that. When openSUSE 10.3 goes out of maintenance
> (end of 2009), we can even drop support for kernels < 2.6.25.
> 
> [1] http://fedoraproject.org/wiki/LifeCycle
> [2] http://en.opensuse.org/SUSE_Linux_Lifetime
> 
> There is a reason why the Linux market has been segmented into
> enterprise distributions and community distributions. Ignoring that
> reason and trying to support all distributions with the same upstream
> repository simply doesn't work.
> 
> So, I don't buy your claim that we should either support old enterprise
> kernels or not support any old kernel at all. Just like I don't buy
> your claim that the technical aspect shouldn't be taken into account
> when deciding what kernels you want to support. I think we have to be
> pragmatic here. We want to support kernels which users really care
> about (and these are the ones in maintained popular non-enterprise
> distributions) and which don't cost too much to support from a
> technical point of view.

---

> Now, if you think that giving up the hg tree and only supporting Linus'
> latest kernel is the way to go, I'm not going to prevent you from going
> down that road. As a kernel developer, that would make me very happy.
> But I remember that the hg tree is there to help users test the newest
> developments without running a bleeding-edge kernel, and that certainly

---

I don't want to come up with old stories about what happened in the
past, there are some.

It looks like Jean tries to find a good compromise.

So, I don't deny, that recent Fedora stuff is not as stable as it was
for long and on certain hardware, at least, a pain. You are forced to
use something you don't want, giving the test monkey.

We, from our side, should try best, that it does not slip further
away ...

Hans decided deliberately to extend backward compat even down to 2.6.16,
now seeing the bill.

We had back then already requests to prepare compat down to v4l2
revision one, if someone remembers and I did strongly deny such
assaults. Our head developers were set on wrong paths and wasted there
time. Result in best case was some binary only.

So, if Hans wants to get out of this hell now, seems down to 2.6.22 he
would be willing to help to care for, the rest is as it was.

Mauro, Trent, Mike and hopefully some more for the rest or let it.

Cheers,
Hermann

Re: Minimum kernel version supported by v4l-dvb

[Hans Verkuil]

On Friday 20 February 2009 04:57:11 hermann pitton wrote:
> Hi,
>
<cut>
> ---
>
> I don't want to come up with old stories about what happened in the
> past, there are some.
>
> It looks like Jean tries to find a good compromise.
>
> So, I don't deny, that recent Fedora stuff is not as stable as it was
> for long and on certain hardware, at least, a pain. You are forced to
> use something you don't want, giving the test monkey.
>
> We, from our side, should try best, that it does not slip further
> away ...
>
> Hans decided deliberately to extend backward compat even down to 2.6.16,
> now seeing the bill.

I didn't extend it, instead I reduced the backward compat to 2.6.16 at the 
time. It supported older kernels as well back then, however since nobody 
ever compiled for those older kernels quite a few drivers were broken.

Creating the daily build system at least ensures that we know v4l-dvb can 
compile for those kernels we support officially. In the past this was more 
based on hope and a prayer :-)

> We had back then already requests to prepare compat down to v4l2
> revision one, if someone remembers and I did strongly deny such
> assaults. Our head developers were set on wrong paths and wasted there
> time. Result in best case was some binary only.
>
> So, if Hans wants to get out of this hell now, seems down to 2.6.22 he
> would be willing to help to care for, the rest is as it was.
>
> Mauro, Trent, Mike and hopefully some more for the rest or let it.
>
> Cheers,
> Hermann

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Minimum kernel version supported by v4l-dvb

[Jean Delvare]

On Fri, 20 Feb 2009 07:53:16 +0100, Hans Verkuil wrote:
> On Friday 20 February 2009 04:57:11 hermann pitton wrote:
> > Hans decided deliberately to extend backward compat even down to 2.6.16,
> > now seeing the bill.
> 
> I didn't extend it, instead I reduced the backward compat to 2.6.16 at the 
> time. It supported older kernels as well back then, however since nobody 
> ever compiled for those older kernels quite a few drivers were broken.
> 
> Creating the daily build system at least ensures that we know v4l-dvb can 
> compile for those kernels we support officially. In the past this was more 
> based on hope and a prayer :-)

That's better than before, but just because it builds doesn't mean it
works...

-- 
Jean Delvare

Re: Minimum kernel version supported by v4l-dvb

[hermann pitton]

Am Freitag, den 20.02.2009, 10:49 +0100 schrieb Jean Delvare:
> On Fri, 20 Feb 2009 07:53:16 +0100, Hans Verkuil wrote:
> > On Friday 20 February 2009 04:57:11 hermann pitton wrote:
> > > Hans decided deliberately to extend backward compat even down to 2.6.16,
> > > now seeing the bill.
> > 
> > I didn't extend it, instead I reduced the backward compat to 2.6.16 at the 
> > time. It supported older kernels as well back then, however since nobody 
> > ever compiled for those older kernels quite a few drivers were broken.
> > 
> > Creating the daily build system at least ensures that we know v4l-dvb can 
> > compile for those kernels we support officially. In the past this was more 
> > based on hope and a prayer :-)
> 
> That's better than before, but just because it builds doesn't mean it
> works...
> 

Given the restricted testing (!) capabilities in both directions, I
don't even know how many and different devices we support currently and
that it works is not always guaranteed on a released kernel either :)

Does Linus know it better ;)

Cheers,
Hermann

Re: Minimum kernel version supported by v4l-dvb

[Mauro Carvalho Chehab]

On Wed, 18 Feb 2009 14:01:05 +0100
Jean Delvare <khali@linux-fr.org> wrote:

> Hi Mauro,
> 
> On Wed, 18 Feb 2009 07:10:41 -0300, Mauro Carvalho Chehab wrote:
> > On Wed, 18 Feb 2009 09:55:53 +0100 (CET)
> > "Hans Verkuil" <hverkuil@xs4all.nl> wrote:
> > 
> > > Not at all. I work with embedded systems and what happens is that you
> > > effectively take a kernel snapshot for your device and stick to that.
> > > You're not using v4l-dvb, but you might backport important fixes on
> > > occasion.
> > > 
> > > Again, it's not our job. The linux model is to get your drivers into the
> > > kernel, then let distros take care of the rest, which includes backporting
> > > if needed to older kernels. We are doing the work that distros should be
> > > doing. A few years ago I moved ivtv to v4l-dvb and the kernel with the
> > > express purpose to be finally free of keeping it backwards compatible with
> > > older kernels. Now I find myself doing the same AGAIN.
> > > 
> > > And you are talking about that mythical user that needs it. I've yet to
> > > SEE that user here and telling me that it is essential to their product.
> > > 
> > > PROVE to me that it is really necessary and really our job, and esp. my
> > > job, since *I'm* the one keeping the backwards compatibility for i2c
> > > modules alive. All I hear is 'there might be', 'I know some company', 'I
> > > heard'.
> > > 
> > > Right now there is crappy code in the kernel whose only purpose is to
> > > facilitate support for old kernels. That's actually against the kernel
> > > policy.
> > > 
> > > One alternative is it create a separate repository just before the compat
> > > code is removed, and merge important fixes for drivers in there. That
> > > should tide us over until RHEL 6 is released.
> > > 
> > > Which also raises the other question: what criterium is there anyway to
> > > decide what is the oldest kernel to support? RHEL 5 will no doubt be used
> > > for 1-2 years after RHEL 6 is release, do we still keep support for that?
> > > Old kernels will be used for a long time in embedded systems, do we still
> > > keep support for that too?
> > 
> > Hans, I'm doing backport since 2005. So, you are not the only one that are
> > doing backports. On V4L, this started ever since. In the case of DVB, we
> > started backport on 2006. Before that, they use to support only the latest
> > kernel version.
> > 
> > If you get a snapshot of our tree of about 6 months to one year ago, we had
> > even support for linux-2.4 I2C (and yes, this works - I have a tree here for
> > vivi and bttv drivers based on that i2c support, working with 2.4).
> 
> 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.
 
> > In the past, our criteria were simply to support all 2.6 versions and the
> > latest 2.4 versions. Sometime after having the last 2.4 distro moving their
> > stable repo to 2.6, we decided to drop 2.4, because we got no complains to keep
> > 2.4 on that time.
> > 
> > Maybe the current solution for i2c backport is not the better one, and we
> > need to use another approach. If the current i2c backport is interfering on the
> > development, then maybe we need to re-think about the backport implementation.
> > The backport shouldn't affect the upstream. It were never affected until the
> > recent i2c backport. Even the 2.4 i2c backport didn't interfere upstream, even
> > having a completely different implementation on 2.4.
> 
> Actually, 2.6 kernels up to 2.6.13 had an i2c API very similar to what
> 2.4 had. The binding model changes we are undergoing now are way more
> intrusive than the migration from 2.4 to early 2.6.

This is true for the drivers that are using the newer model. However, there are
still several drivers that use the old model (bttv, em28xx, cx88 - maybe
others). 

I think that maybe we'll need some legacy-like support for bttv and cx88, since
there are some boards that relies on the old i2c method to work. On those
boards (like cx88 Pixelview), the same board model (and PCB revision) may or
may not have a separate audio decoder. On those devices that have an audio
decoder, the widely used solution is to load tvaudio module and let it bind at
the i2c bus, on such cases.

> > > The only reasonable criterium I see is technical: when you start to
> > > introduce cruft into the kernel just to support older kernels, then it is
> > > time to cut off support to those kernels.
> > 
> > The criteria for backport is not technical.
> 
> That technical isn't the only criteria, I agree with. But claiming that
> technical isn't a criteria at all is plain wrong. This is equivalent to
> claiming that development time doesn't cost anything.

Well, what's the technical criteria? I don't see much #if's inside the i2c part
of the drivers.

> >                                       (...) It is all about offering a version
> > that testers with standard distros can use it, without needing to use the
> > latest -rc kernel.
> > 
> > I'm fine to drop support to unused kernels, but the hole idea to have backport
> > is to allow an easy usage of the newer drivers by users with their environment.
> > If we start removing such code, due to any other criteria different than having
> > support for kernels that people are still using on their desktop and enterprise
> > environments, 
> 
> You're aiming at the wrong target, I am afraid. "Enterprise
> environments" have _nothing_ to do with upstream development, by
> definition. More on that below.
> 
> >         (...) then it is time to forget about -hg and use -git instead,
> > supporting only the latest tip kernel, just like almost all other maintainers
> > do.
> > 
> > While we are stick on have backport, we need at least to support the latest
> > desktop and enterprise kernel versions of the major distros.
> > 
> > So, it is a matter of deciding what we want:
> > 	keep our current criteria of offering backport kernels that include
> > 	at least the kernel version used on the major desktop and enterprise
> > 	kernel distros
> 
> No, not enterprise kernels!
> 
> > OR
> > 	just use -git and drop all backport code.
> > 
> > Both solutions work for me, although I prefer to keep backport, even having more trouble[1]. 
> > 
> > Anything else and we will enter of a grey area that will likely go nowhere.
> 
> I am sorry but I don't follow you here. You are basically claiming that
> allowing enterprise users (who typically run RHEL or SLED) to build
> bleeding-edge drivers off the v4l-dvb repository is very important, but
> allowing non-enterprise users and kernel developers (who typically run
> Fedora or openSUSE) isn't that important? I believe this is exactly the
> other way around.

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

> I am working on L3 support for SLE products, so I know very well what
> enterprise customers want, and what they don't. I doubt that RHEL
> customers are any different from SLE ones. Enterprise customers don't
> give a damn to the v4l-dvb repository. All they know about and want are
> packages provided by the vendor, which change as little as possible
> (that is, bug fixes only.) Running bleeding-edge, untrusted and
> unmaintained drivers is the last thing they want. If they need a driver
> for a recent piece of hardware, they open a feature request for the
> next service pack, and leave it to the OS vendor to backport the
> driver and maintain it for the next 5 years or so.

True. But it is also true that there are some free versions based on those
enterprise kernels that also use the same base system.

I'm not trying to defend any particular distro here. The point is: there are a
large amount of different V4L/DVB devices. I doubt that the developers will
ever have all boards in the market. That's basically the reason why we support
backport. We should really try to have the largest base of testers that it is
possible. If we are excluding people from the community because of the
diversity of their environments, we will likely loose some important feedbacks.

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

> The actual audience for the v4l-dvb repository is users who do NOT have
> a support contract with the OS vendor. That is, home users. These do
> not run RHEL and SLE, especially if they have recent hardware, given
> how bad hardware support is in enterprise distributions. Home users
> will want their hard disk controller, graphics adapter and sound chip
> to work before they even consider getting support for their TV adapter
> from the v4l-dvb repository. Which means that they will be running a
> recent version of Fedora, openSUSE or equivalent.
> 
> Now, if you look at the support policy of Fedora and openSUSE, you'll
> see that they are maintained for 13 [1] to 24 [2] months. In practice,
> the oldest supported Fedora is Fedora 9, featuring kernel 2.6.25, and
> the oldest supported openSUSE is openSUSE 10.3, featuring kernel
> 2.6.22. Which is why I claim that there is no point in supporting
> anything older than that. When openSUSE 10.3 goes out of maintenance
> (end of 2009), we can even drop support for kernels < 2.6.25.
> 
> [1] http://fedoraproject.org/wiki/LifeCycle
> [2] http://en.opensuse.org/SUSE_Linux_Lifetime
> 
> There is a reason why the Linux market has been segmented into
> enterprise distributions and community distributions. Ignoring that
> reason and trying to support all distributions with the same upstream
> repository simply doesn't work.
> 
> So, I don't buy your claim that we should either support old enterprise
> kernels or not support any old kernel at all. Just like I don't buy
> your claim that the technical aspect shouldn't be taken into account
> when deciding what kernels you want to support. I think we have to be
> pragmatic here. We want to support kernels which users really care
> about (and these are the ones in maintained popular non-enterprise
> distributions) and which don't cost too much to support from a
> technical point of view.

Now, the issue is of a different nature. Since I do most of the backports on
v4l-dvb, I can say that the big effort happens when an API changes upstream.
Let's take, for example, the last dvbnet changes: They moved some data from a
priv struct into a net core struct. This happened sometime during 2.6.29-rc
cycle.

The trivial solution, done by most maintainers, is to just use 2.6.29-rc
kernel as the basis for development. No backport efforts are needed. They can
focus their work looking ahead.

In our case, if we want the same code to work with 2.6.28 and 2.6.29-rc, we
need to find a creative way to backport the patch without adding much #ifs
(using for example compat.h), or to add those #ifs at the code.

Either way, after the backport patch, there's no need to maintain the
backport, especially if we use the v4l/scripts/make_config_compat.pl script.

The backported code inside the #ifs don't need to be changed.

Ok, having lots of #if's inside the code looks ugly, but those if's and the
compat code are removed upstream, so, developers can see the upstream code
without any backport [1].

So, the issue here is not preserving the backport patches forever, but,
instead, the need for someone to do the backports. This is time consuming and
requires a developer that could be doing drivers improvements instead of
loosing time with backports.

In fact, Hans is not the only one developer asking for dropping -hg and use
-git instead. Several others already asked this publicly or in priv. Using a
different model from the rest of the subsystems is not scaling well anymore. We
have almost 300 different drivers, and the current number of commits per day is
very high.

I think we should really consider some alternatives to use -git (with the
standard kernel tree there), instead of our current model.

Maybe we should have some sort of scripts to auto-generate tarballs with
backport patches inside (alsa has a model like this). They are now using -git
for development, and stopped using -hg. The issue here is that we should take
some time to think on how this will work, and design a set of scripts to
generate the backport tree.

[1] In the very specific case of i2c, Hans adopted a different solution, due to
the need to emulate the old i2c behaviour for drivers that weren't ported to
the new i2c. In order to cleanup the code, we need first to port all drivers to
the new i2c model. Then, we can implement the i2c backport on the same way as
all the other drivers.

> Now, if you think that giving up the hg tree and only supporting Linus'
> latest kernel is the way to go, I'm not going to prevent you from going
> down that road. As a kernel developer, that would make me very happy.
> But I remember that the hg tree is there to help users test the newest
> developments without running a bleeding-edge kernel, and that certainly
> makes some sense.

I agree that we shouldn't just use -git and forget about all the users of
v4l-dvb hg tree. That's why I've asked Hans to open a separate thread: in order
to remove -hg, in favor of -git, we need to have some solutions to keep
allowing the users to compile and test with their environments, without asking
they to upgrade to the latest kernel version. So, we'll need good ideas and
volunteers to implement.

Cheers,
Mauro

Re: Minimum kernel version supported by v4l-dvb

[Hans Verkuil]

On Saturday 21 February 2009 01:23:27 Mauro Carvalho Chehab wrote:
> On Wed, 18 Feb 2009 14:01:05 +0100
>
> Jean Delvare <khali@linux-fr.org> wrote:
> > Hi Mauro,
> >
> > On Wed, 18 Feb 2009 07:10:41 -0300, Mauro Carvalho Chehab wrote:
> > > On Wed, 18 Feb 2009 09:55:53 +0100 (CET)
> > >
> > > "Hans Verkuil" <hverkuil@xs4all.nl> wrote:
> > > > Not at all. I work with embedded systems and what happens is that
> > > > you effectively take a kernel snapshot for your device and stick to
> > > > that. You're not using v4l-dvb, but you might backport important
> > > > fixes on occasion.
> > > >
> > > > Again, it's not our job. The linux model is to get your drivers
> > > > into the kernel, then let distros take care of the rest, which
> > > > includes backporting if needed to older kernels. We are doing the
> > > > work that distros should be doing. A few years ago I moved ivtv to
> > > > v4l-dvb and the kernel with the express purpose to be finally free
> > > > of keeping it backwards compatible with older kernels. Now I find
> > > > myself doing the same AGAIN.
> > > >
> > > > And you are talking about that mythical user that needs it. I've
> > > > yet to SEE that user here and telling me that it is essential to
> > > > their product.
> > > >
> > > > PROVE to me that it is really necessary and really our job, and
> > > > esp. my job, since *I'm* the one keeping the backwards
> > > > compatibility for i2c modules alive. All I hear is 'there might
> > > > be', 'I know some company', 'I heard'.
> > > >
> > > > Right now there is crappy code in the kernel whose only purpose is
> > > > to facilitate support for old kernels. That's actually against the
> > > > kernel policy.
> > > >
> > > > One alternative is it create a separate repository just before the
> > > > compat code is removed, and merge important fixes for drivers in
> > > > there. That should tide us over until RHEL 6 is released.
> > > >
> > > > Which also raises the other question: what criterium is there
> > > > anyway to decide what is the oldest kernel to support? RHEL 5 will
> > > > no doubt be used for 1-2 years after RHEL 6 is release, do we still
> > > > keep support for that? Old kernels will be used for a long time in
> > > > embedded systems, do we still keep support for that too?
> > >
> > > Hans, I'm doing backport since 2005. So, you are not the only one
> > > that are doing backports. On V4L, this started ever since. In the
> > > case of DVB, we started backport on 2006. Before that, they use to
> > > support only the latest kernel version.
> > >
> > > If you get a snapshot of our tree of about 6 months to one year ago,
> > > we had even support for linux-2.4 I2C (and yes, this works - I have a
> > > tree here for vivi and bttv drivers based on that i2c support,
> > > working with 2.4).
> >
> > 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.
>
> > > In the past, our criteria were simply to support all 2.6 versions and
> > > the latest 2.4 versions. Sometime after having the last 2.4 distro
> > > moving their stable repo to 2.6, we decided to drop 2.4, because we
> > > got no complains to keep 2.4 on that time.
> > >
> > > Maybe the current solution for i2c backport is not the better one,
> > > and we need to use another approach. If the current i2c backport is
> > > interfering on the development, then maybe we need to re-think about
> > > the backport implementation. The backport shouldn't affect the
> > > upstream. It were never affected until the recent i2c backport. Even
> > > the 2.4 i2c backport didn't interfere upstream, even having a
> > > completely different implementation on 2.4.
> >
> > Actually, 2.6 kernels up to 2.6.13 had an i2c API very similar to what
> > 2.4 had. The binding model changes we are undergoing now are way more
> > intrusive than the migration from 2.4 to early 2.6.
>
> This is true for the drivers that are using the newer model. However,
> there are still several drivers that use the old model (bttv, em28xx,
> cx88 - maybe others).
>
> I think that maybe we'll need some legacy-like support for bttv and cx88,
> since there are some boards that relies on the old i2c method to work. On
> those boards (like cx88 Pixelview), the same board model (and PCB
> revision) may or may not have a separate audio decoder. On those devices
> that have an audio decoder, the widely used solution is to load tvaudio
> module and let it bind at the i2c bus, on such cases.

That's what the i2c_new_probed_device() call is for (called through 
v4l2_i2c_new_probed_subdev). You pass a list of i2c addresses that the i2c 
core will probe for you: but this comes from the adapter driver, not from 
the i2c module. And that makes all the difference. So bttv, cx88, etc. are 
all on my list to be converted. The drivers pvrusb2, cx18 and em28xx are 
already being converted by Mike Isely, Andy Walls and Douglas Landgraf. I'm 
doing usbvision and w9968cf. I have already done zoran, vino and cafe_ccic 
which are waiting for test results. That leaves bttv, cx88 and cx23885 
which still need a volunteer.

> > > > The only reasonable criterium I see is technical: when you start to
> > > > introduce cruft into the kernel just to support older kernels, then
> > > > it is time to cut off support to those kernels.
> > >
> > > The criteria for backport is not technical.
> >
> > That technical isn't the only criteria, I agree with. But claiming that
> > technical isn't a criteria at all is plain wrong. This is equivalent to
> > claiming that development time doesn't cost anything.
>
> Well, what's the technical criteria? I don't see much #if's inside the
> i2c part of the drivers.

Look in include/media/v4l2-i2c-drv*.h and v4l2-common.c. That's why I 
created these headers: to keep the #if's to a minimum in the actual i2c 
modules. The -legacy variant is really bad, but when I'm done with the 
conversion it can actually disappear, so in all fairness we can ignore that 
header.

But v4l2-i2c-drv.h is bad enough, and even worse is what it looks like in 
the kernel when the compat code has been stripped from it: it's turned into 
a completely pointless header. And all the v4l2 i2c modules look peculiar 
as well due to that header include.

> > >                                       (...) It is all about offering
> > > a version that testers with standard distros can use it, without
> > > needing to use the latest -rc kernel.
> > >
> > > I'm fine to drop support to unused kernels, but the hole idea to have
> > > backport is to allow an easy usage of the newer drivers by users with
> > > their environment. If we start removing such code, due to any other
> > > criteria different than having support for kernels that people are
> > > still using on their desktop and enterprise environments,
> >
> > You're aiming at the wrong target, I am afraid. "Enterprise
> > environments" have _nothing_ to do with upstream development, by
> > definition. More on that below.
> >
> > >         (...) then it is time to forget about -hg and use -git
> > > instead, supporting only the latest tip kernel, just like almost all
> > > other maintainers do.
> > >
> > > While we are stick on have backport, we need at least to support the
> > > latest desktop and enterprise kernel versions of the major distros.
> > >
> > > So, it is a matter of deciding what we want:
> > > 	keep our current criteria of offering backport kernels that include
> > > 	at least the kernel version used on the major desktop and enterprise
> > > 	kernel distros
> >
> > No, not enterprise kernels!
> >
> > > OR
> > > 	just use -git and drop all backport code.
> > >
> > > Both solutions work for me, although I prefer to keep backport, even
> > > having more trouble[1].
> > >
> > > Anything else and we will enter of a grey area that will likely go
> > > nowhere.
> >
> > I am sorry but I don't follow you here. You are basically claiming that
> > allowing enterprise users (who typically run RHEL or SLED) to build
> > bleeding-edge drivers off the v4l-dvb repository is very important, but
> > allowing non-enterprise users and kernel developers (who typically run
> > Fedora or openSUSE) isn't that important? I believe this is exactly the
> > other way around.
>
> 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).
>
> > I am working on L3 support for SLE products, so I know very well what
> > enterprise customers want, and what they don't. I doubt that RHEL
> > customers are any different from SLE ones. Enterprise customers don't
> > give a damn to the v4l-dvb repository. All they know about and want are
> > packages provided by the vendor, which change as little as possible
> > (that is, bug fixes only.) Running bleeding-edge, untrusted and
> > unmaintained drivers is the last thing they want. If they need a driver
> > for a recent piece of hardware, they open a feature request for the
> > next service pack, and leave it to the OS vendor to backport the
> > driver and maintain it for the next 5 years or so.
>
> True. But it is also true that there are some free versions based on
> those enterprise kernels that also use the same base system.
>
> I'm not trying to defend any particular distro here. The point is: there
> are a large amount of different V4L/DVB devices. I doubt that the
> developers will ever have all boards in the market. That's basically the
> reason why we support backport. We should really try to have the largest
> base of testers that it is possible. If we are excluding people from the
> community because of the diversity of their environments, we will likely
> loose some important feedbacks.
>
> > 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.

I've no problem with that. However, there is a trade-off here between the 
effort required to maintain the compat code and the extra complexity it 
creates in the code (do not underestimate that!), and the number of people 
actually using that particular kernel version. That balance is lost at the 
moment IMHO.

> > The actual audience for the v4l-dvb repository is users who do NOT have
> > a support contract with the OS vendor. That is, home users. These do
> > not run RHEL and SLE, especially if they have recent hardware, given
> > how bad hardware support is in enterprise distributions. Home users
> > will want their hard disk controller, graphics adapter and sound chip
> > to work before they even consider getting support for their TV adapter
> > from the v4l-dvb repository. Which means that they will be running a
> > recent version of Fedora, openSUSE or equivalent.
> >
> > Now, if you look at the support policy of Fedora and openSUSE, you'll
> > see that they are maintained for 13 [1] to 24 [2] months. In practice,
> > the oldest supported Fedora is Fedora 9, featuring kernel 2.6.25, and
> > the oldest supported openSUSE is openSUSE 10.3, featuring kernel
> > 2.6.22. Which is why I claim that there is no point in supporting
> > anything older than that. When openSUSE 10.3 goes out of maintenance
> > (end of 2009), we can even drop support for kernels < 2.6.25.
> >
> > [1] http://fedoraproject.org/wiki/LifeCycle
> > [2] http://en.opensuse.org/SUSE_Linux_Lifetime
> >
> > There is a reason why the Linux market has been segmented into
> > enterprise distributions and community distributions. Ignoring that
> > reason and trying to support all distributions with the same upstream
> > repository simply doesn't work.
> >
> > So, I don't buy your claim that we should either support old enterprise
> > kernels or not support any old kernel at all. Just like I don't buy
> > your claim that the technical aspect shouldn't be taken into account
> > when deciding what kernels you want to support. I think we have to be
> > pragmatic here. We want to support kernels which users really care
> > about (and these are the ones in maintained popular non-enterprise
> > distributions) and which don't cost too much to support from a
> > technical point of view.
>
> Now, the issue is of a different nature. Since I do most of the backports
> on v4l-dvb, I can say that the big effort happens when an API changes
> upstream. Let's take, for example, the last dvbnet changes: They moved
> some data from a priv struct into a net core struct. This happened
> sometime during 2.6.29-rc cycle.
>
> The trivial solution, done by most maintainers, is to just use 2.6.29-rc
> kernel as the basis for development. No backport efforts are needed. They
> can focus their work looking ahead.
>
> In our case, if we want the same code to work with 2.6.28 and 2.6.29-rc,
> we need to find a creative way to backport the patch without adding much
> #ifs (using for example compat.h), or to add those #ifs at the code.
>
> Either way, after the backport patch, there's no need to maintain the
> backport, especially if we use the v4l/scripts/make_config_compat.pl
> script.

The compat.h mechanism works fine, and anything that can be handled there 
will not cause any problems whatsoever in maintaining the backwards compat.

> The backported code inside the #ifs don't need to be changed.
>
> Ok, having lots of #if's inside the code looks ugly, but those if's and
> the compat code are removed upstream, so, developers can see the upstream
> code without any backport [1].

It's ugly and that makes it hard to understand and maintain the code. It is 
OK (within limits) for a while, but only if with a certain regularity you 
can drop support for the oldest kernels and so remove the #ifs for those 
kernels. This will keep the code from becoming infested with ever 
increasing amounts of #ifs.

Also (having just read your note [1]) the compat code for the i2c module had 
nothing to do with the transition of converting our drivers to the new i2c 
API, it has to do with the fact that even after that conversion we still 
have to support kernels < 2.6.22 that do not have that new i2c API. And the 
models are so different that I see no good alternative.

> So, the issue here is not preserving the backport patches forever, but,
> instead, the need for someone to do the backports. This is time consuming
> and requires a developer that could be doing drivers improvements instead
> of loosing time with backports.
>
> In fact, Hans is not the only one developer asking for dropping -hg and
> use -git instead. Several others already asked this publicly or in priv.
> Using a different model from the rest of the subsystems is not scaling
> well anymore. We have almost 300 different drivers, and the current
> number of commits per day is very high.
>
> I think we should really consider some alternatives to use -git (with the
> standard kernel tree there), instead of our current model.
>
> Maybe we should have some sort of scripts to auto-generate tarballs with
> backport patches inside (alsa has a model like this). They are now using
> -git for development, and stopped using -hg. The issue here is that we
> should take some time to think on how this will work, and design a set of
> scripts to generate the backport tree.

As long as we intend to provide some sort of backwards compatibility we will 
hit the same problem: for how long will you keep supporting kernels? And 
the reason why the i2c part is so hard is that it isn't a case of changed 
data structures or some data that's been move from one place to another, 
but it is a complete change in the i2c model. And the solutions to that end 
up affecting the code as it appears in the kernel, and that's really bad.

> [1] In the very specific case of i2c, Hans adopted a different solution,
> due to the need to emulate the old i2c behaviour for drivers that weren't
> ported to the new i2c. In order to cleanup the code, we need first to
> port all drivers to the new i2c model. Then, we can implement the i2c
> backport on the same way as all the other drivers.
>
> > Now, if you think that giving up the hg tree and only supporting Linus'
> > latest kernel is the way to go, I'm not going to prevent you from going
> > down that road. As a kernel developer, that would make me very happy.
> > But I remember that the hg tree is there to help users test the newest
> > developments without running a bleeding-edge kernel, and that certainly
> > makes some sense.
>
> I agree that we shouldn't just use -git and forget about all the users of
> v4l-dvb hg tree. That's why I've asked Hans to open a separate thread: in
> order to remove -hg, in favor of -git, we need to have some solutions to
> keep allowing the users to compile and test with their environments,
> without asking they to upgrade to the latest kernel version. So, we'll
> need good ideas and volunteers to implement.

I'll write the document tomorrow (hmm, 2 AM, it's tomorrow already :-) ).

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Minimum kernel version supported by v4l-dvb

[kilgota]

On Fri, 20 Feb 2009, Mauro Carvalho Chehab wrote:

> On Wed, 18 Feb 2009 14:01:05 +0100
> Jean Delvare <khali@linux-fr.org> wrote:
>
>> Hi Mauro,
>>
>> On Wed, 18 Feb 2009 07:10:41 -0300, Mauro Carvalho Chehab wrote:
>>> On Wed, 18 Feb 2009 09:55:53 +0100 (CET)
>>> "Hans Verkuil" <hverkuil@xs4all.nl> wrote:
>>>
>>>> Not at all. I work with embedded systems and what happens is that you
>>>> effectively take a kernel snapshot for your device and stick to that.
>>>> You're not using v4l-dvb, but you might backport important fixes on
>>>> occasion.
>>>>
>>>> Again, it's not our job. The linux model is to get your drivers into the
>>>> kernel, then let distros take care of the rest, which includes backporting
>>>> if needed to older kernels. We are doing the work that distros should be
>>>> doing. A few years ago I moved ivtv to v4l-dvb and the kernel with the
>>>> express purpose to be finally free of keeping it backwards compatible with
>>>> older kernels. Now I find myself doing the same AGAIN.
>>>>
>>>> And you are talking about that mythical user that needs it. I've yet to
>>>> SEE that user here and telling me that it is essential to their product.
>>>>
>>>> PROVE to me that it is really necessary and really our job, and esp. my
>>>> job, since *I'm* the one keeping the backwards compatibility for i2c
>>>> modules alive. All I hear is 'there might be', 'I know some company', 'I
>>>> heard'.
>>>>
>>>> Right now there is crappy code in the kernel whose only purpose is to
>>>> facilitate support for old kernels. That's actually against the kernel
>>>> policy.
>>>>
>>>> One alternative is it create a separate repository just before the compat
>>>> code is removed, and merge important fixes for drivers in there. That
>>>> should tide us over until RHEL 6 is released.
>>>>
>>>> Which also raises the other question: what criterium is there anyway to
>>>> decide what is the oldest kernel to support? RHEL 5 will no doubt be used
>>>> for 1-2 years after RHEL 6 is release, do we still keep support for that?
>>>> Old kernels will be used for a long time in embedded systems, do we still
>>>> keep support for that too?
>>>
>>> Hans, I'm doing backport since 2005. So, you are not the only one that are
>>> doing backports. On V4L, this started ever since. In the case of DVB, we
>>> started backport on 2006. Before that, they use to support only the latest
>>> kernel version.
>>>
>>> If you get a snapshot of our tree of about 6 months to one year ago, we had
>>> even support for linux-2.4 I2C (and yes, this works - I have a tree here for
>>> vivi and bttv drivers based on that i2c support, working with 2.4).
>>
>> 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.
>
>>> In the past, our criteria were simply to support all 2.6 versions and the
>>> latest 2.4 versions. Sometime after having the last 2.4 distro moving their
>>> stable repo to 2.6, we decided to drop 2.4, because we got no complains to keep
>>> 2.4 on that time.
>>>
>>> Maybe the current solution for i2c backport is not the better one, and we
>>> need to use another approach. If the current i2c backport is interfering on the
>>> development, then maybe we need to re-think about the backport implementation.
>>> The backport shouldn't affect the upstream. It were never affected until the
>>> recent i2c backport. Even the 2.4 i2c backport didn't interfere upstream, even
>>> having a completely different implementation on 2.4.
>>
>> Actually, 2.6 kernels up to 2.6.13 had an i2c API very similar to what
>> 2.4 had. The binding model changes we are undergoing now are way more
>> intrusive than the migration from 2.4 to early 2.6.
>
> This is true for the drivers that are using the newer model. However, there are
> still several drivers that use the old model (bttv, em28xx, cx88 - maybe
> others).
>
> I think that maybe we'll need some legacy-like support for bttv and cx88, since
> there are some boards that relies on the old i2c method to work. On those
> boards (like cx88 Pixelview), the same board model (and PCB revision) may or
> may not have a separate audio decoder. On those devices that have an audio
> decoder, the widely used solution is to load tvaudio module and let it bind at
> the i2c bus, on such cases.
>
>>>> The only reasonable criterium I see is technical: when you start to
>>>> introduce cruft into the kernel just to support older kernels, then it is
>>>> time to cut off support to those kernels.
>>>
>>> The criteria for backport is not technical.
>>
>> That technical isn't the only criteria, I agree with. But claiming that
>> technical isn't a criteria at all is plain wrong. This is equivalent to
>> claiming that development time doesn't cost anything.
>
> Well, what's the technical criteria? I don't see much #if's inside the i2c part
> of the drivers.
>
>>>                                       (...) It is all about offering a version
>>> that testers with standard distros can use it, without needing to use the
>>> latest -rc kernel.
>>>
>>> I'm fine to drop support to unused kernels, but the hole idea to have backport
>>> is to allow an easy usage of the newer drivers by users with their environment.
>>> If we start removing such code, due to any other criteria different than having
>>> support for kernels that people are still using on their desktop and enterprise
>>> environments,
>>
>> You're aiming at the wrong target, I am afraid. "Enterprise
>> environments" have _nothing_ to do with upstream development, by
>> definition. More on that below.
>>
>>>         (...) then it is time to forget about -hg and use -git instead,
>>> supporting only the latest tip kernel, just like almost all other maintainers
>>> do.
>>>
>>> While we are stick on have backport, we need at least to support the latest
>>> desktop and enterprise kernel versions of the major distros.
>>>
>>> So, it is a matter of deciding what we want:
>>> 	keep our current criteria of offering backport kernels that include
>>> 	at least the kernel version used on the major desktop and enterprise
>>> 	kernel distros
>>
>> No, not enterprise kernels!
>>
>>> OR
>>> 	just use -git and drop all backport code.
>>>
>>> Both solutions work for me, although I prefer to keep backport, even having more trouble[1].
>>>
>>> Anything else and we will enter of a grey area that will likely go nowhere.
>>
>> I am sorry but I don't follow you here. You are basically claiming that
>> allowing enterprise users (who typically run RHEL or SLED) to build
>> bleeding-edge drivers off the v4l-dvb repository is very important, but
>> allowing non-enterprise users and kernel developers (who typically run
>> Fedora or openSUSE) isn't that important? I believe this is exactly the
>> other way around.
>
> 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).
>
>> I am working on L3 support for SLE products, so I know very well what
>> enterprise customers want, and what they don't. I doubt that RHEL
>> customers are any different from SLE ones. Enterprise customers don't
>> give a damn to the v4l-dvb repository. All they know about and want are
>> packages provided by the vendor, which change as little as possible
>> (that is, bug fixes only.) Running bleeding-edge, untrusted and
>> unmaintained drivers is the last thing they want. If they need a driver
>> for a recent piece of hardware, they open a feature request for the
>> next service pack, and leave it to the OS vendor to backport the
>> driver and maintain it for the next 5 years or so.
>
> True. But it is also true that there are some free versions based on those
> enterprise kernels that also use the same base system.
>
> I'm not trying to defend any particular distro here. The point is: there are a
> large amount of different V4L/DVB devices. I doubt that the developers will
> ever have all boards in the market. That's basically the reason why we support
> backport. We should really try to have the largest base of testers that it is
> possible. If we are excluding people from the community because of the
> diversity of their environments, we will likely loose some important feedbacks.
>
>> 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.
>
>> The actual audience for the v4l-dvb repository is users who do NOT have
>> a support contract with the OS vendor. That is, home users. These do
>> not run RHEL and SLE, especially if they have recent hardware, given
>> how bad hardware support is in enterprise distributions. Home users
>> will want their hard disk controller, graphics adapter and sound chip
>> to work before they even consider getting support for their TV adapter
>> from the v4l-dvb repository. Which means that they will be running a
>> recent version of Fedora, openSUSE or equivalent.
>>
>> Now, if you look at the support policy of Fedora and openSUSE, you'll
>> see that they are maintained for 13 [1] to 24 [2] months. In practice,
>> the oldest supported Fedora is Fedora 9, featuring kernel 2.6.25, and
>> the oldest supported openSUSE is openSUSE 10.3, featuring kernel
>> 2.6.22. Which is why I claim that there is no point in supporting
>> anything older than that. When openSUSE 10.3 goes out of maintenance
>> (end of 2009), we can even drop support for kernels < 2.6.25.
>>
>> [1] http://fedoraproject.org/wiki/LifeCycle
>> [2] http://en.opensuse.org/SUSE_Linux_Lifetime
>>
>> There is a reason why the Linux market has been segmented into
>> enterprise distributions and community distributions. Ignoring that
>> reason and trying to support all distributions with the same upstream
>> repository simply doesn't work.
>>
>> So, I don't buy your claim that we should either support old enterprise
>> kernels or not support any old kernel at all. Just like I don't buy
>> your claim that the technical aspect shouldn't be taken into account
>> when deciding what kernels you want to support. I think we have to be
>> pragmatic here. We want to support kernels which users really care
>> about (and these are the ones in maintained popular non-enterprise
>> distributions) and which don't cost too much to support from a
>> technical point of view.
>
> Now, the issue is of a different nature. Since I do most of the backports on
> v4l-dvb, I can say that the big effort happens when an API changes upstream.
> Let's take, for example, the last dvbnet changes: They moved some data from a
> priv struct into a net core struct. This happened sometime during 2.6.29-rc
> cycle.
>
> The trivial solution, done by most maintainers, is to just use 2.6.29-rc
> kernel as the basis for development. No backport efforts are needed. They can
> focus their work looking ahead.
>
> In our case, if we want the same code to work with 2.6.28 and 2.6.29-rc, we
> need to find a creative way to backport the patch without adding much #ifs
> (using for example compat.h), or to add those #ifs at the code.
>
> Either way, after the backport patch, there's no need to maintain the
> backport, especially if we use the v4l/scripts/make_config_compat.pl script.
>
> The backported code inside the #ifs don't need to be changed.
>
> Ok, having lots of #if's inside the code looks ugly, but those if's and the
> compat code are removed upstream, so, developers can see the upstream code
> without any backport [1].
>
> So, the issue here is not preserving the backport patches forever, but,
> instead, the need for someone to do the backports. This is time consuming and
> requires a developer that could be doing drivers improvements instead of
> loosing time with backports.
>
> In fact, Hans is not the only one developer asking for dropping -hg and use
> -git instead. Several others already asked this publicly or in priv. Using a
> different model from the rest of the subsystems is not scaling well anymore. We
> have almost 300 different drivers, and the current number of commits per day is
> very high.
>
> I think we should really consider some alternatives to use -git (with the
> standard kernel tree there), instead of our current model.
>
> Maybe we should have some sort of scripts to auto-generate tarballs with
> backport patches inside (alsa has a model like this). They are now using -git
> for development, and stopped using -hg. The issue here is that we should take
> some time to think on how this will work, and design a set of scripts to
> generate the backport tree.
>
> [1] In the very specific case of i2c, Hans adopted a different solution, due to
> the need to emulate the old i2c behaviour for drivers that weren't ported to
> the new i2c. In order to cleanup the code, we need first to port all drivers to
> the new i2c model. Then, we can implement the i2c backport on the same way as
> all the other drivers.
>
>> Now, if you think that giving up the hg tree and only supporting Linus'
>> latest kernel is the way to go, I'm not going to prevent you from going
>> down that road. As a kernel developer, that would make me very happy.
>> But I remember that the hg tree is there to help users test the newest
>> developments without running a bleeding-edge kernel, and that certainly
>> makes some sense.
>
> I agree that we shouldn't just use -git and forget about all the users of
> v4l-dvb hg tree. That's why I've asked Hans to open a separate thread: in order
> to remove -hg, in favor of -git, we need to have some solutions to keep
> allowing the users to compile and test with their environments, without asking
> they to upgrade to the latest kernel version. So, we'll need good ideas and
> volunteers to implement.
>
> Cheers,
> Mauro

Hoping that I can offer some helpful comments on this thread, as someone 
who came along only in the last couple of months or so:

1. One of the most interesting features which I found in the video for 
Linux project is the ability to work somewhat independently of the 
particular kernel version running on the local machine. This is valuable, 
in the sense that it saves a lot of wasted time and effort just keeping up 
with which kernel version to use. It was also something which is done so 
cleverly that at first I could not believe it. Congratulations to those 
who thought this arrangement up.

2. Sometimes, there is a real problem with a particular version of the 
kernel which has nothing to do with the task at hand, but it sure can get 
in the way. As a recent example, soon after starting to work with Adam 
Baker on the sq905 module (and furthermore having at the time the false 
impression that the gspca work meant I should be running the latest thing 
out there) I upgraded from 2.6.27.7 to 2.6.28. Well, there was a rather 
serious USB bug in 2.6.28. So then _that_ had to be straightened out. 
Things like that do not promote smooth progress but rather interfere with 
it.

3. I just bought an eeePC. It is running some 2.6.21.x kernel. My 
reaction: I do not believe they should be doing that. I would not feel 
like accommodating them. Comparison: someone wrote to me complaining about 
problems with libgphoto2-2.1.3, which his distro was still releasing, when 
libgphoto2-2.3.x was already out and his problem had been solved 24 months 
before. I told him to upgrade and his problems would go away. He wanted me 
to fix his old version. I explained that this has been done, and he should 
avail himself of that by installing a new version. Somewhere there is a 
line, and that guy crossed it.

Trying to put all this together:

I think that the semi-independence from the particular kernel-du-jour is a 
good thing and would seem to me to make progress in the specific area of 
video to be smoother. Modular or semi-modular development is something 
nice. One can concentrate on the subject at hand and not on daily kernel 
upgrading. Nice.

I also would not want to bust my butt to support someone's ancient kernel. 
After all, quite often the reason there is a new kernel version is that 
some long-undiscovered bug suddenly got discovered. Not all change is 
just for fun, or just to support new stuff. Some of those bugs had 
far-reaching consequences, recall. So to support one of the affected 
kernels involves what, exactly?

Hoping that these comments help toward some good conclusion of this issue.

Theodore Kilgore

Re: Minimum kernel version supported by v4l-dvb

[Mauro Carvalho Chehab]

On Sat, 21 Feb 2009 02:12:53 +0100
Hans Verkuil <hverkuil@xs4all.nl> wrote:

> > I think that maybe we'll need some legacy-like support for bttv and cx88,
> > since there are some boards that relies on the old i2c method to work. On
> > those boards (like cx88 Pixelview), the same board model (and PCB
> > revision) may or may not have a separate audio decoder. On those devices
> > that have an audio decoder, the widely used solution is to load tvaudio
> > module and let it bind at the i2c bus, on such cases.
> 
> That's what the i2c_new_probed_device() call is for (called through 
> v4l2_i2c_new_probed_subdev). You pass a list of i2c addresses that the i2c 
> core will probe for you: but this comes from the adapter driver, not from 
> the i2c module. 

This is a problem. The current procedure used by end users will stop working.
It is a little worse: as the adapter driver has no means to know that some
device could need tvaudio or other similar devices, we would need some hacking
to allow the user to pass a parameter to the driver in order to test/load such
drivers, since there's no documentation of when such things are needed.

> And that makes all the difference. So bttv, cx88, etc. are 
> all on my list to be converted. The drivers pvrusb2, cx18 and em28xx are 
> already being converted by Mike Isely, Andy Walls and Douglas Landgraf. I'm 
> doing usbvision and w9968cf. I have already done zoran, vino and cafe_ccic 
> which are waiting for test results. That leaves bttv, cx88 and cx23885 
> which still need a volunteer.

The worse one will be bttv. For sure there are several cases where users need
to load the i2c modules by hand.

On cx88, the only case I know is with Pixelview Ultra Pro devices. Yet, I dunno
how to properly solve it. The manufacturer chipped a dozen of different boards,
all of them without eeproms - so using the generic address - and most using the
same PCB revision. 

I've seen models of PV ultra with Philips 1236 tuners, with Tena tuners, with
TI-based tuners, with tvaudio and without tvaudio chips, with tea5767, without
tea5767... There's no external indication about what's inside the device. All
of them are branded with the same name and the same model number.

> > > > > The only reasonable criterium I see is technical: when you start to
> > > > > introduce cruft into the kernel just to support older kernels, then
> > > > > it is time to cut off support to those kernels.
> > > >
> > > > The criteria for backport is not technical.
> > >
> > > That technical isn't the only criteria, I agree with. But claiming that
> > > technical isn't a criteria at all is plain wrong. This is equivalent to
> > > claiming that development time doesn't cost anything.
> >
> > Well, what's the technical criteria? I don't see much #if's inside the
> > i2c part of the drivers.
> 
> Look in include/media/v4l2-i2c-drv*.h and v4l2-common.c. That's why I 
> created these headers: to keep the #if's to a minimum in the actual i2c 
> modules. The -legacy variant is really bad, but when I'm done with the 
> conversion it can actually disappear, so in all fairness we can ignore that 
> header.
> 
> But v4l2-i2c-drv.h is bad enough, and even worse is what it looks like in 
> the kernel when the compat code has been stripped from it: it's turned into 
> a completely pointless header. And all the v4l2 i2c modules look peculiar 
> as well due to that header include.

IMO, we should first focus on removing the legacy code. Even on v4l2-common.c,
we have some tricks due to legacy support. After removing the legacy code, I
suspect that the code will be simpler to understand the code and to find other
ways to preserve compatibility if needed. I suspect that just removing 2.6.22
or lower support is not enough to remove v4l2-i2c-drv.h.

> > Maybe we should have some sort of scripts to auto-generate tarballs with
> > backport patches inside (alsa has a model like this). They are now using
> > -git for development, and stopped using -hg. The issue here is that we
> > should take some time to think on how this will work, and design a set of
> > scripts to generate the backport tree.
> 
> As long as we intend to provide some sort of backwards compatibility we will 
> hit the same problem: for how long will you keep supporting kernels? And 
> the reason why the i2c part is so hard is that it isn't a case of changed 
> data structures or some data that's been move from one place to another, 
> but it is a complete change in the i2c model. And the solutions to that end 
> up affecting the code as it appears in the kernel, and that's really bad.

Eventually, things could be easier if we found better model. For example, a
configure script could seek for a particular string on a kernel header. If not
found, it may apply a patch, or run a parser to replace one code into another.

This way, the development code won't have any #if's or compat code. I'm afraid
that just using patches may also bring another range of troubles of needing to
periodically maintain the backports. On the other hand, a syntax/semantic
parser would be much more complex to develop.

> > I agree that we shouldn't just use -git and forget about all the users of
> > v4l-dvb hg tree. That's why I've asked Hans to open a separate thread: in
> > order to remove -hg, in favor of -git, we need to have some solutions to
> > keep allowing the users to compile and test with their environments,
> > without asking they to upgrade to the latest kernel version. So, we'll
> > need good ideas and volunteers to implement.
> 
> I'll write the document tomorrow (hmm, 2 AM, it's tomorrow already :-) ).
Ok.

Cheers,
Mauro

Re: Minimum kernel version supported by v4l-dvb

[Mauro Carvalho Chehab]

Hi Theodore,

On Fri, 20 Feb 2009 19:30:16 -0600 (CST)
kilgota@banach.math.auburn.edu wrote:

> Hoping that I can offer some helpful comments on this thread, as someone 
> who came along only in the last couple of months or so:
> 
> 1. One of the most interesting features which I found in the video for 
> Linux project is the ability to work somewhat independently of the 
> particular kernel version running on the local machine. This is valuable, 
> in the sense that it saves a lot of wasted time and effort just keeping up 
> with which kernel version to use. It was also something which is done so 
> cleverly that at first I could not believe it. Congratulations to those 
> who thought this arrangement up.
> 
> 2. Sometimes, there is a real problem with a particular version of the 
> kernel which has nothing to do with the task at hand, but it sure can get 
> in the way. As a recent example, soon after starting to work with Adam 
> Baker on the sq905 module (and furthermore having at the time the false 
> impression that the gspca work meant I should be running the latest thing 
> out there) I upgraded from 2.6.27.7 to 2.6.28. Well, there was a rather 
> serious USB bug in 2.6.28. So then _that_ had to be straightened out. 
> Things like that do not promote smooth progress but rather interfere with 
> it.
> 
> 3. I just bought an eeePC. It is running some 2.6.21.x kernel. My 
> reaction: I do not believe they should be doing that. I would not feel 
> like accommodating them. Comparison: someone wrote to me complaining about 
> problems with libgphoto2-2.1.3, which his distro was still releasing, when 
> libgphoto2-2.3.x was already out and his problem had been solved 24 months 
> before. I told him to upgrade and his problems would go away. He wanted me 
> to fix his old version. I explained that this has been done, and he should 
> avail himself of that by installing a new version. Somewhere there is a 
> line, and that guy crossed it.
> 
> Trying to put all this together:
> 
> I think that the semi-independence from the particular kernel-du-jour is a 
> good thing and would seem to me to make progress in the specific area of 
> video to be smoother. Modular or semi-modular development is something 
> nice. One can concentrate on the subject at hand and not on daily kernel 
> upgrading. Nice.
> 
> I also would not want to bust my butt to support someone's ancient kernel. 
> After all, quite often the reason there is a new kernel version is that 
> some long-undiscovered bug suddenly got discovered. Not all change is 
> just for fun, or just to support new stuff. Some of those bugs had 
> far-reaching consequences, recall. So to support one of the affected 
> kernels involves what, exactly?
> 
> Hoping that these comments help toward some good conclusion of this issue.

Thank you for your comments.

For sure allowing to compile v4l-dvb with older kernels is very interesting for
the users. It is not perfect, since a bug upstream will keep affecting the
backported driver, but, in general, this works well, however, at the cost of
spending developers time backporting things. Since the size of the tree is
increasing a lot, we'll likely need to use another solution.


Cheers,
Mauro

Re: Minimum kernel version supported by v4l-dvb

[hermann pitton]

Hi,

[...]
> The worse one will be bttv. For sure there are several cases where users need
> to load the i2c modules by hand.
> 
> On cx88, the only case I know is with Pixelview Ultra Pro devices. Yet, I dunno
> how to properly solve it. The manufacturer chipped a dozen of different boards,
> all of them without eeproms - so using the generic address - and most using the
> same PCB revision. 
> 
> I've seen models of PV ultra with Philips 1236 tuners, with Tena tuners, with
> TI-based tuners, with tvaudio and without tvaudio chips, with tea5767, without
> tea5767... There's no external indication about what's inside the device. All
> of them are branded with the same name and the same model number.

this is no myth or something. It was hard work and I totally agree with
Mauro about what has happened.

Hermann

Re: Minimum kernel version supported by v4l-dvb

[Hans Verkuil]

On Saturday 21 February 2009 03:13:50 Mauro Carvalho Chehab wrote:
> On Sat, 21 Feb 2009 02:12:53 +0100
>
> Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > I think that maybe we'll need some legacy-like support for bttv and
> > > cx88, since there are some boards that relies on the old i2c method
> > > to work. On those boards (like cx88 Pixelview), the same board model
> > > (and PCB revision) may or may not have a separate audio decoder. On
> > > those devices that have an audio decoder, the widely used solution is
> > > to load tvaudio module and let it bind at the i2c bus, on such cases.
> >
> > That's what the i2c_new_probed_device() call is for (called through
> > v4l2_i2c_new_probed_subdev). You pass a list of i2c addresses that the
> > i2c core will probe for you: but this comes from the adapter driver,
> > not from the i2c module.
>
> This is a problem. The current procedure used by end users will stop
> working. It is a little worse: as the adapter driver has no means to know
> that some device could need tvaudio or other similar devices, we would
> need some hacking to allow the user to pass a parameter to the driver in
> order to test/load such drivers, since there's no documentation of when
> such things are needed.

No big deal. Yes, we have to add module options for that, and in the 
parameter description we can point to this list with the request that the 
fact that you have to set this 'autoload_tvaudio' module option is passed 
on to us so we can fix our card definitions. Easy to implement and we 
hopefully get feedback about this. Not converting is not an option as the 
autoprobe behavior will be removed by Jean (and good riddance). This is 
unrelated with backwards compatibility issues, this is a fact of life.

> > And that makes all the difference. So bttv, cx88, etc. are
> > all on my list to be converted. The drivers pvrusb2, cx18 and em28xx
> > are already being converted by Mike Isely, Andy Walls and Douglas
> > Landgraf. I'm doing usbvision and w9968cf. I have already done zoran,
> > vino and cafe_ccic which are waiting for test results. That leaves
> > bttv, cx88 and cx23885 which still need a volunteer.
>
> The worse one will be bttv. For sure there are several cases where users
> need to load the i2c modules by hand.
>
> On cx88, the only case I know is with Pixelview Ultra Pro devices. Yet, I
> dunno how to properly solve it. The manufacturer chipped a dozen of
> different boards, all of them without eeproms - so using the generic
> address - and most using the same PCB revision.
>
> I've seen models of PV ultra with Philips 1236 tuners, with Tena tuners,
> with TI-based tuners, with tvaudio and without tvaudio chips, with
> tea5767, without tea5767... There's no external indication about what's
> inside the device. All of them are branded with the same name and the
> same model number.

If you know it is this card, then you can try to probe for all of these 
devices. The good think about the new approach is that you can do these 
probes safely since they will only happen on the i2c adapter of the card in 
question, so you can make sure that no eeprom or other important devices 
are being probed that shouldn't have. In other words: you get deterministic 
behavior and control over what you are doing.

> > > > > > The only reasonable criterium I see is technical: when you
> > > > > > start to introduce cruft into the kernel just to support older
> > > > > > kernels, then it is time to cut off support to those kernels.
> > > > >
> > > > > The criteria for backport is not technical.
> > > >
> > > > That technical isn't the only criteria, I agree with. But claiming
> > > > that technical isn't a criteria at all is plain wrong. This is
> > > > equivalent to claiming that development time doesn't cost anything.
> > >
> > > Well, what's the technical criteria? I don't see much #if's inside
> > > the i2c part of the drivers.
> >
> > Look in include/media/v4l2-i2c-drv*.h and v4l2-common.c. That's why I
> > created these headers: to keep the #if's to a minimum in the actual i2c
> > modules. The -legacy variant is really bad, but when I'm done with the
> > conversion it can actually disappear, so in all fairness we can ignore
> > that header.
> >
> > But v4l2-i2c-drv.h is bad enough, and even worse is what it looks like
> > in the kernel when the compat code has been stripped from it: it's
> > turned into a completely pointless header. And all the v4l2 i2c modules
> > look peculiar as well due to that header include.
>
> IMO, we should first focus on removing the legacy code. Even on
> v4l2-common.c, we have some tricks due to legacy support. After removing
> the legacy code, I suspect that the code will be simpler to understand
> the code and to find other ways to preserve compatibility if needed. I
> suspect that just removing 2.6.22 or lower support is not enough to
> remove v4l2-i2c-drv.h.

OK, once more: there are two types of legacy code: one is that drivers have 
to be switched to use the new i2c API. That's what I've been working on all 
these months since Plumbers 2008. When all drivers that use i2c modules 
have been converted, then we can drop v4l2-i2c-drv-legacy.h and Jean can 
drop the autoprobing code in the i2c core.

The second type of legacy code is that if we want to support kernels older 
than 2.6.22, then we STILL have to support the old autoprobing model. 
That's what v4l2-i2c-drv.h and v4l2_i2c_legacy_find_client() and 
v4l2_i2c_attach() in v4l2-common.c are for. And there is no easy solution 
for this.

And yes, when support for kernels pre-2.6.22 is dropped, then all of this 
can disappear. There are still a few #ifs, but those are for the 
more 'normal' datastructure changes that happened in 2.6.26. In my reply to 
this thread on Wednesday I showed how an i2c module would look if we can 
drop support for these older kernels. Perfectly acceptable IMHO.

Please, I've been working on this together with Jean for a year or more, I 
know what I'm talking about.

> > > Maybe we should have some sort of scripts to auto-generate tarballs
> > > with backport patches inside (alsa has a model like this). They are
> > > now using -git for development, and stopped using -hg. The issue here
> > > is that we should take some time to think on how this will work, and
> > > design a set of scripts to generate the backport tree.
> >
> > As long as we intend to provide some sort of backwards compatibility we
> > will hit the same problem: for how long will you keep supporting
> > kernels? And the reason why the i2c part is so hard is that it isn't a
> > case of changed data structures or some data that's been move from one
> > place to another, but it is a complete change in the i2c model. And the
> > solutions to that end up affecting the code as it appears in the
> > kernel, and that's really bad.
>
> Eventually, things could be easier if we found better model. For example,
> a configure script could seek for a particular string on a kernel header.
> If not found, it may apply a patch, or run a parser to replace one code
> into another.
>
> This way, the development code won't have any #if's or compat code. I'm
> afraid that just using patches may also bring another range of troubles
> of needing to periodically maintain the backports. On the other hand, a
> syntax/semantic parser would be much more complex to develop.

I saw an article on lwn about the Coccinelle tool: 
http://lwn.net/Articles/315069/

I very much doubt this will be any help with this i2c problem, but for other 
transformations it may very well be useful. Unfortunately it is written in 
OCaml, in the best tradition of universities of developing a great idea but 
implementing it in an obscure programming language :-(

Regards,

	Hans

> > > I agree that we shouldn't just use -git and forget about all the
> > > users of v4l-dvb hg tree. That's why I've asked Hans to open a
> > > separate thread: in order to remove -hg, in favor of -git, we need to
> > > have some solutions to keep allowing the users to compile and test
> > > with their environments, without asking they to upgrade to the latest
> > > kernel version. So, we'll need good ideas and volunteers to
> > > implement.
> >
> > I'll write the document tomorrow (hmm, 2 AM, it's tomorrow already :-)
> > ).
>
> Ok.
>
> Cheers,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Minimum kernel version supported by v4l-dvb

[Jean Delvare]

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

Re: Minimum kernel version supported by v4l-dvb

[Mauro Carvalho Chehab]

On Wed, 18 Feb 2009 00:06:38 +0100
Hans Verkuil <hverkuil@xs4all.nl> wrote:

> Especially companies like Texas Instruments that 
> are working on new v4l2 drivers for the embedded space (omap, davinci) are 
> quite annoyed and confused by all the backwards compatibility stuff that 
> we're dragging along. I find it much more important to cater to their needs 
> than to support a driver on an ancient kernel for some anonymous company. 

The i2c code or any other backported code shouldn't affect any new driver. 

For new drivers, they can just use 2.6.29-rc as reference and mark
that the minimum required version for it is 2.6.30, at v4l/versions.txt. 

If the driver is for x86/x86_64, it generally makes sense to preserve the
backward compat bits, to help users.

However, in the specific case of TI development, for OMAP and similar drivers
that are specific to some embedded architecture, and where a normal user will
never need to test it for us, since the vendor is responsible for the driver,
it is perfectly fine to update v4l/versions.txt for each new version that needs
something for a newer API.

Cheers,
Mauro

Re: Minimum kernel version supported by v4l-dvb

[Mauro Carvalho Chehab]

On Sat, 21 Feb 2009 08:28:50 +0100
Hans Verkuil <hverkuil@xs4all.nl> wrote:

> On Saturday 21 February 2009 03:13:50 Mauro Carvalho Chehab wrote:
> > On Sat, 21 Feb 2009 02:12:53 +0100
> >
> > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > > I think that maybe we'll need some legacy-like support for bttv and
> > > > cx88, since there are some boards that relies on the old i2c method
> > > > to work. On those boards (like cx88 Pixelview), the same board model
> > > > (and PCB revision) may or may not have a separate audio decoder. On
> > > > those devices that have an audio decoder, the widely used solution is
> > > > to load tvaudio module and let it bind at the i2c bus, on such cases.
> > >
> > > That's what the i2c_new_probed_device() call is for (called through
> > > v4l2_i2c_new_probed_subdev). You pass a list of i2c addresses that the
> > > i2c core will probe for you: but this comes from the adapter driver,
> > > not from the i2c module.
> >
> > This is a problem. The current procedure used by end users will stop
> > working. It is a little worse: as the adapter driver has no means to know
> > that some device could need tvaudio or other similar devices, we would
> > need some hacking to allow the user to pass a parameter to the driver in
> > order to test/load such drivers, since there's no documentation of when
> > such things are needed.
> 
> No big deal. Yes, we have to add module options for that, and in the 
> parameter description we can point to this list with the request that the 
> fact that you have to set this 'autoload_tvaudio' module option is passed 
> on to us so we can fix our card definitions. Easy to implement and we 
> hopefully get feedback about this.

I think you're underestimating the complexity here.

By adding such options, the effect for a normal user is that they'll complain
that "after upgrading my distro from FOO to BAR, my board broke". Also, since
we have 14 different audio modules, adding 14 new autoload_foo, this seems too
much hacking.

If we take a look on the supported devices, almost all have their own
(sometimes limited) audio processor. This is not the case for bt848/bt878. The
conversion of this driver will probably be harder than the conversion of the
other drivers, since it requires more ancillary devices than the others and
since the developers have only a very small subset of the amount of supported
cards. Also, this chip has more than 12 years of life. It were used with almost
all different generations of audio (and video, video enhancer, videotext)
decoder chips.

On bttv, we can clearly see that several devices rely on the manual loading
method. For example, this is what we have on bttv Kconfig:

        select VIDEO_MSP3400 if VIDEO_HELPER_CHIPS_AUTO
        select VIDEO_TVAUDIO if VIDEO_HELPER_CHIPS_AUTO
        select VIDEO_TDA7432 if VIDEO_HELPER_CHIPS_AUTO
        select VIDEO_TDA9875 if VIDEO_HELPER_CHIPS_AUTO

This brings the false impression that only 4 audio modules would be needed.
However, if you take a look on bttv-audio-hook.c, we can see that other audio
modules are needed, due to a few comments there, like:

<snip>
 * Looks like it's needed only for the "tvphone", the "tvphone 98"
 * handles this with a tda9840
</snip>

tda9840 support is provided by tda9840.ko, but there's no request_module() or
any other reference (except for the above comment) to it at bttv driver. I
believe that this is not an isolated case.

I suspect that there are other cases where no doc is provided on kernel and the
only source of information is provided by googling at the net or by taking a
look on each card at bttv-gallery to see what chips are inside of each bttv
board.

So, at least for bttv, IMO, we should: do an i2c scan, on bttv driver, for
tvaudio and the other audio modules. If found, then we load the proper
driver. 

We'll still have another problem: There are conflicting addresses. For
example, address 0xb0 (8bit notation) is used on tvaudio for tda9874 and on
tda9875. I have no idea what boards need tvaudio and what boards need tda9875
module. So, simply probing for 0xb0 won't be enough.

During the conversion of bttv to V4L2, I've mapped the i2c addresses of the
audio modules I found at:

	linux/include/media/i2c-addr.h

For cx88, the issue is simpler, since cx88 has its own audio decoder. I dunno
why some PV boards have a separate audio processor[1]. Anyway, for cx88, we can
add the autodetection code just for that device, and just for tvaudio.

for the other drivers, I suspect we don't have such issues, since the audio
decoder became part of the design of the modern chips[2].

> Not converting is not an option as the 
> autoprobe behavior will be removed by Jean (and good riddance). This is 
> unrelated with backwards compatibility issues, this is a fact of life.

Before removing, we need to solve the above cases to avoid regression on the
existing drivers.

> > I've seen models of PV ultra with Philips 1236 tuners, with Tena tuners,
> > with TI-based tuners, with tvaudio and without tvaudio chips, with
> > tea5767, without tea5767... There's no external indication about what's
> > inside the device. All of them are branded with the same name and the
> > same model number.
> 
> If you know it is this card, then you can try to probe for all of these 
> devices.

In this specific case, I know, since I own one of those PV boards, and I'm the
one that added support for it. So, sometimes people talk with me in priv about
this specific device. I don't have any list of what other devices need this kind
of approach.

> The good think about the new approach is that you can do these 
> probes safely since they will only happen on the i2c adapter of the card in 
> question, so you can make sure that no eeprom or other important devices 
> are being probed that shouldn't have. In other words: you get deterministic 
> behavior and control over what you are doing.

With the current way, it works fine, since:
	- tea5767 is auto-detected;
	- different tuners are passed via modprobe option by the user;
	- tvaudio is loaded via modprobe.

For sure for this board, we can automate the autoload of tvaudio, for the ones
that need it. This will be a good improvement.

We'll still need to use the modprobe options for tuner (and for board, since it
uses the generic Conexant PCI ID's).

> > IMO, we should first focus on removing the legacy code. Even on
> > v4l2-common.c, we have some tricks due to legacy support. After removing
> > the legacy code, I suspect that the code will be simpler to understand
> > the code and to find other ways to preserve compatibility if needed. I
> > suspect that just removing 2.6.22 or lower support is not enough to
> > remove v4l2-i2c-drv.h.
> 
> OK, once more: there are two types of legacy code: one is that drivers have 
> to be switched to use the new i2c API. That's what I've been working on all 
> these months since Plumbers 2008. When all drivers that use i2c modules 
> have been converted, then we can drop v4l2-i2c-drv-legacy.h and Jean can 
> drop the autoprobing code in the i2c core.

This will be great, provided that we can do the autoprobing for the audio
modules as required by a few drivers like bttv.

> The second type of legacy code is that if we want to support kernels older 
> than 2.6.22, then we STILL have to support the old autoprobing model. 
> That's what v4l2-i2c-drv.h and v4l2_i2c_legacy_find_client() and 
> v4l2_i2c_attach() in v4l2-common.c are for. And there is no easy solution 
> for this.

The easiest solution would be to just add a large series of #ifs (sigh!). I'm
sure we'll find other ways if we still need it, by the time we finish porting
all drivers to the new i2c methods.

> And yes, when support for kernels pre-2.6.22 is dropped, then all of this 
> can disappear. There are still a few #ifs, but those are for the 
> more 'normal' datastructure changes that happened in 2.6.26. In my reply to 
> this thread on Wednesday I showed how an i2c module would look if we can 
> drop support for these older kernels. Perfectly acceptable IMHO.

On that code, you've considered that all the legacy code were removed and that
we dropped support for kernels older than 2.6.26.

Before removing the legacy code and support between 2.6.22 and 2.6.26, you'll
need more compat bits.

> > Eventually, things could be easier if we found better model. For example,
> > a configure script could seek for a particular string on a kernel header.
> > If not found, it may apply a patch, or run a parser to replace one code
> > into another.
> >
> > This way, the development code won't have any #if's or compat code. I'm
> > afraid that just using patches may also bring another range of troubles
> > of needing to periodically maintain the backports. On the other hand, a
> > syntax/semantic parser would be much more complex to develop.
> 
> I saw an article on lwn about the Coccinelle tool: 
> http://lwn.net/Articles/315069/
> 
> I very much doubt this will be any help with this i2c problem, but for other 
> transformations it may very well be useful. Unfortunately it is written in 
> OCaml, in the best tradition of universities of developing a great idea but 
> implementing it in an obscure programming language :-(
 
Being dependent of OCaml practically avoids its usage by normal users. Maybe we
could try to use a lexical analyser like flex (that it is more commonly
installed on distros, since several packages require it on their autoconf
environments to compile some code), or see if there are some other tools that we
could maybe bind together with a backport tarball.

Yet, Coccinelle seems to be very handful. There are several janitor
contributions using it to re-write code.

[1] In a matter of fact, there are 4 different cx88 chips: cx23880, cx23881,
cx23882 and cx23883. The difference between those chips is on the supported
audio standards. Probably they decided to buy just one model (to reduce
prices), or they got out of stock of the proper cx2388x device and had some
spare low-cost audio processors. Who knows?

[2] AFAIK, em28xx doesn't have an audio decoder. The first models came with a
msp3400. The newer ones are using xc3028 with MTS firmware. We recently
discovered one variant of an existing card that uses an unsupported audio
decoder.

Cheers,
Mauro

Re: Minimum kernel version supported by v4l-dvb

[Hans Verkuil]

On Saturday 21 February 2009 12:50:46 Mauro Carvalho Chehab wrote:
> On Wed, 18 Feb 2009 00:06:38 +0100
>
> Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > Especially companies like Texas Instruments that
> > are working on new v4l2 drivers for the embedded space (omap, davinci)
> > are quite annoyed and confused by all the backwards compatibility stuff
> > that we're dragging along. I find it much more important to cater to
> > their needs than to support a driver on an ancient kernel for some
> > anonymous company.
>
> The i2c code or any other backported code shouldn't affect any new
> driver.
>
> For new drivers, they can just use 2.6.29-rc as reference and mark
> that the minimum required version for it is 2.6.30, at v4l/versions.txt.
>
> If the driver is for x86/x86_64, it generally makes sense to preserve the
> backward compat bits, to help users.
>
> However, in the specific case of TI development, for OMAP and similar
> drivers that are specific to some embedded architecture, and where a
> normal user will never need to test it for us, since the vendor is
> responsible for the driver, it is perfectly fine to update
> v4l/versions.txt for each new version that needs something for a newer
> API.

Not quite true, certainly not in the generic case. If you come from the 
outside and start developing v4l i2c drivers, then it is simply confusing 
when you look at existing drivers in the git tree to use as a model. It's 
not clear at all why we do things the way we do. That's bad.

Secondly, i2c modules developed for embedded systems are perfectly usable in 
e.g. webcams which you might want to support for older kernels. It's not an 
issue right now though, as long as soc-camera and int-dev aren't converted 
to use v4l2_subdev as that prevents them from being used this way.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Minimum kernel version supported by v4l-dvb

[Trent Piepho]

On Fri, 20 Feb 2009, Mauro Carvalho Chehab wrote:
> On Sat, 21 Feb 2009 02:12:53 +0100
> Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > I think that maybe we'll need some legacy-like support for bttv and cx88,
> > > since there are some boards that relies on the old i2c method to work. On
> > > those boards (like cx88 Pixelview), the same board model (and PCB
> > > revision) may or may not have a separate audio decoder. On those devices
> > > that have an audio decoder, the widely used solution is to load tvaudio
> > > module and let it bind at the i2c bus, on such cases.
> >
> > That's what the i2c_new_probed_device() call is for (called through
> > v4l2_i2c_new_probed_subdev). You pass a list of i2c addresses that the i2c
> > core will probe for you: but this comes from the adapter driver, not from
> > the i2c module.
>
> This is a problem. The current procedure used by end users will stop working.
> It is a little worse: as the adapter driver has no means to know that some
> device could need tvaudio or other similar devices, we would need some hacking
> to allow the user to pass a parameter to the driver in order to test/load such
> drivers, since there's no documentation of when such things are needed.

The new i2c driver interface also supports a ->detect() method and a list
of address_data to use it with.  This is much more like the legacy model
than using i2c_new_probed_device().

I think a compatability layer than implements attach_adapter,
detach_adapter, and detach_client using a new-style driver's detect, probe,
remove, and address_data should not be that hard.

> > But v4l2-i2c-drv.h is bad enough, and even worse is what it looks like in
> > the kernel when the compat code has been stripped from it: it's turned into
> > a completely pointless header. And all the v4l2 i2c modules look peculiar
> > as well due to that header include.

As I've said before, the v4l2-i2c headers are lot more complicated than
they need to be.  I have a tree that's shrunk them greatly.  I don't think
it's fair to give the current headers as an example of how complicated i2c
backward compat _must_ be.

> This way, the development code won't have any #if's or compat code. I'm afraid
> that just using patches may also bring another range of troubles of needing to
> periodically maintain the backports. On the other hand, a syntax/semantic
> parser would be much more complex to develop.

IMHO, the ALSA method of providing a backward compatability package is much
inferior to the way v4l-dvb is doings thing.

Re: Minimum kernel version supported by v4l-dvb

[Hans Verkuil]

On Saturday 21 February 2009 12:58:01 Mauro Carvalho Chehab wrote:
> On Sat, 21 Feb 2009 08:28:50 +0100
>
> Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > On Saturday 21 February 2009 03:13:50 Mauro Carvalho Chehab wrote:
> > > On Sat, 21 Feb 2009 02:12:53 +0100
> > >
> > > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > > > I think that maybe we'll need some legacy-like support for bttv
> > > > > and cx88, since there are some boards that relies on the old i2c
> > > > > method to work. On those boards (like cx88 Pixelview), the same
> > > > > board model (and PCB revision) may or may not have a separate
> > > > > audio decoder. On those devices that have an audio decoder, the
> > > > > widely used solution is to load tvaudio module and let it bind at
> > > > > the i2c bus, on such cases.
> > > >
> > > > That's what the i2c_new_probed_device() call is for (called through
> > > > v4l2_i2c_new_probed_subdev). You pass a list of i2c addresses that
> > > > the i2c core will probe for you: but this comes from the adapter
> > > > driver, not from the i2c module.
> > >
> > > This is a problem. The current procedure used by end users will stop
> > > working. It is a little worse: as the adapter driver has no means to
> > > know that some device could need tvaudio or other similar devices, we
> > > would need some hacking to allow the user to pass a parameter to the
> > > driver in order to test/load such drivers, since there's no
> > > documentation of when such things are needed.
> >
> > No big deal. Yes, we have to add module options for that, and in the
> > parameter description we can point to this list with the request that
> > the fact that you have to set this 'autoload_tvaudio' module option is
> > passed on to us so we can fix our card definitions. Easy to implement
> > and we hopefully get feedback about this.
>
> I think you're underestimating the complexity here.
>
> By adding such options, the effect for a normal user is that they'll
> complain that "after upgrading my distro from FOO to BAR, my board
> broke". Also, since we have 14 different audio modules, adding 14 new
> autoload_foo, this seems too much hacking.
>
> If we take a look on the supported devices, almost all have their own
> (sometimes limited) audio processor. This is not the case for
> bt848/bt878. The conversion of this driver will probably be harder than
> the conversion of the other drivers, since it requires more ancillary
> devices than the others and since the developers have only a very small
> subset of the amount of supported cards. Also, this chip has more than 12
> years of life. It were used with almost all different generations of
> audio (and video, video enhancer, videotext) decoder chips.
>
> On bttv, we can clearly see that several devices rely on the manual
> loading method. For example, this is what we have on bttv Kconfig:
>
>         select VIDEO_MSP3400 if VIDEO_HELPER_CHIPS_AUTO
>         select VIDEO_TVAUDIO if VIDEO_HELPER_CHIPS_AUTO
>         select VIDEO_TDA7432 if VIDEO_HELPER_CHIPS_AUTO
>         select VIDEO_TDA9875 if VIDEO_HELPER_CHIPS_AUTO
>
> This brings the false impression that only 4 audio modules would be
> needed. However, if you take a look on bttv-audio-hook.c, we can see that
> other audio modules are needed, due to a few comments there, like:
>
> <snip>
>  * Looks like it's needed only for the "tvphone", the "tvphone 98"
>  * handles this with a tda9840
> </snip>
>
> tda9840 support is provided by tda9840.ko, but there's no
> request_module() or any other reference (except for the above comment) to
> it at bttv driver. I believe that this is not an isolated case.

The tda9840 is handled by tvaudio. Other than tda9875 and msp3400 all these 
audio variants are all handled by that module. tvaudio was developed at the 
time as a sort of 'catch-all' module and is currently only used by bttv.

If you look at the code you'll se that tda9840.c can only be used with 
saa7146, ditto tea6420.c. So these give no conflicts.

> I suspect that there are other cases where no doc is provided on kernel
> and the only source of information is provided by googling at the net or
> by taking a look on each card at bttv-gallery to see what chips are
> inside of each bttv board.
>
> So, at least for bttv, IMO, we should: do an i2c scan, on bttv driver,
> for tvaudio and the other audio modules. If found, then we load the
> proper driver.
>
> We'll still have another problem: There are conflicting addresses. For
> example, address 0xb0 (8bit notation) is used on tvaudio for tda9874 and
> on tda9875. I have no idea what boards need tvaudio and what boards need
> tda9875 module. So, simply probing for 0xb0 won't be enough.

Luckily the two chips can be told apart from one another. Suggestion: move 
the support for tda9874 from tvaudio.c to tda9875.c and let that one handle 
both. They are very similar and that shouldn't be difficult. That will 
solve this conflict in an elegant manner.

I see one more conflict between msp3400 and tea6300. It should be possible 
to implement i2c detect support in msp3400 since that chip can detect what 
chip it is, and if no msp3400 is found after all we fall back to tvaudio.

> During the conversion of bttv to V4L2, I've mapped the i2c addresses of
> the audio modules I found at:
>
> 	linux/include/media/i2c-addr.h
>
> For cx88, the issue is simpler, since cx88 has its own audio decoder. I
> dunno why some PV boards have a separate audio processor[1]. Anyway, for
> cx88, we can add the autodetection code just for that device, and just
> for tvaudio.

Are you sure cx88 requires that tvaudio is loaded for some cards? There is 
no mention about tvaudio and cx88 anywhere, neither source nor 
documentation, nor google for that matter.

> for the other drivers, I suspect we don't have such issues, since the
> audio decoder became part of the design of the modern chips[2].
>
> > Not converting is not an option as the
> > autoprobe behavior will be removed by Jean (and good riddance). This is
> > unrelated with backwards compatibility issues, this is a fact of life.
>
> Before removing, we need to solve the above cases to avoid regression on
> the existing drivers.
>
> > > I've seen models of PV ultra with Philips 1236 tuners, with Tena
> > > tuners, with TI-based tuners, with tvaudio and without tvaudio chips,
> > > with tea5767, without tea5767... There's no external indication about
> > > what's inside the device. All of them are branded with the same name
> > > and the same model number.
> >
> > If you know it is this card, then you can try to probe for all of these
> > devices.
>
> In this specific case, I know, since I own one of those PV boards, and
> I'm the one that added support for it. So, sometimes people talk with me
> in priv about this specific device. I don't have any list of what other
> devices need this kind of approach.
>
> > The good think about the new approach is that you can do these
> > probes safely since they will only happen on the i2c adapter of the
> > card in question, so you can make sure that no eeprom or other
> > important devices are being probed that shouldn't have. In other words:
> > you get deterministic behavior and control over what you are doing.
>
> With the current way, it works fine, since:
> 	- tea5767 is auto-detected;
> 	- different tuners are passed via modprobe option by the user;
> 	- tvaudio is loaded via modprobe.
>
> For sure for this board, we can automate the autoload of tvaudio, for the
> ones that need it. This will be a good improvement.
>
> We'll still need to use the modprobe options for tuner (and for board,
> since it uses the generic Conexant PCI ID's).
>
> > > IMO, we should first focus on removing the legacy code. Even on
> > > v4l2-common.c, we have some tricks due to legacy support. After
> > > removing the legacy code, I suspect that the code will be simpler to
> > > understand the code and to find other ways to preserve compatibility
> > > if needed. I suspect that just removing 2.6.22 or lower support is
> > > not enough to remove v4l2-i2c-drv.h.
> >
> > OK, once more: there are two types of legacy code: one is that drivers
> > have to be switched to use the new i2c API. That's what I've been
> > working on all these months since Plumbers 2008. When all drivers that
> > use i2c modules have been converted, then we can drop
> > v4l2-i2c-drv-legacy.h and Jean can drop the autoprobing code in the i2c
> > core.
>
> This will be great, provided that we can do the autoprobing for the audio
> modules as required by a few drivers like bttv.

You cannot expect that a user can modprobe an i2c driver and it will 
magically appear. That's going away. You can change the driver so that it 
will load the module and let it probe for a series of i2c addresses. There 
is also an option to let the i2c driver do additional checks (Jean knows 
more about the details).

> > The second type of legacy code is that if we want to support kernels
> > older than 2.6.22, then we STILL have to support the old autoprobing
> > model. That's what v4l2-i2c-drv.h and v4l2_i2c_legacy_find_client() and
> > v4l2_i2c_attach() in v4l2-common.c are for. And there is no easy
> > solution for this.
>
> The easiest solution would be to just add a large series of #ifs (sigh!).
> I'm sure we'll find other ways if we still need it, by the time we finish
> porting all drivers to the new i2c methods.
>
> > And yes, when support for kernels pre-2.6.22 is dropped, then all of
> > this can disappear. There are still a few #ifs, but those are for the
> > more 'normal' datastructure changes that happened in 2.6.26. In my
> > reply to this thread on Wednesday I showed how an i2c module would look
> > if we can drop support for these older kernels. Perfectly acceptable
> > IMHO.
>
> On that code, you've considered that all the legacy code were removed and
> that we dropped support for kernels older than 2.6.26.

??? No, the checks for kernel 2.6.26 are still there in the code. I do not 
advocate dropping support for kernels < 2.6.26.

> Before removing the legacy code and support between 2.6.22 and 2.6.26,
> you'll need more compat bits.
>
> > > Eventually, things could be easier if we found better model. For
> > > example, a configure script could seek for a particular string on a
> > > kernel header. If not found, it may apply a patch, or run a parser to
> > > replace one code into another.
> > >
> > > This way, the development code won't have any #if's or compat code.
> > > I'm afraid that just using patches may also bring another range of
> > > troubles of needing to periodically maintain the backports. On the
> > > other hand, a syntax/semantic parser would be much more complex to
> > > develop.
> >
> > I saw an article on lwn about the Coccinelle tool:
> > http://lwn.net/Articles/315069/
> >
> > I very much doubt this will be any help with this i2c problem, but for
> > other transformations it may very well be useful. Unfortunately it is
> > written in OCaml, in the best tradition of universities of developing a
> > great idea but implementing it in an obscure programming language :-(
>
> Being dependent of OCaml practically avoids its usage by normal users.
> Maybe we could try to use a lexical analyser like flex (that it is more
> commonly installed on distros, since several packages require it on their
> autoconf environments to compile some code), or see if there are some
> other tools that we could maybe bind together with a backport tarball.
>
> Yet, Coccinelle seems to be very handful. There are several janitor
> contributions using it to re-write code.
>
> [1] In a matter of fact, there are 4 different cx88 chips: cx23880,
> cx23881, cx23882 and cx23883. The difference between those chips is on
> the supported audio standards. Probably they decided to buy just one
> model (to reduce prices), or they got out of stock of the proper cx2388x
> device and had some spare low-cost audio processors. Who knows?

cx2584x does the same: four variants of the same chip.

Regards,

	Hans

> [2] AFAIK, em28xx doesn't have an audio decoder. The first models came
> with a msp3400. The newer ones are using xc3028 with MTS firmware. We
> recently discovered one variant of an existing card that uses an
> unsupported audio decoder.
>
> Cheers,
> Mauro



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Minimum kernel version supported by v4l-dvb

[Mauro Carvalho Chehab]

On Sat, 21 Feb 2009 13:45:40 +0100
Hans Verkuil <hverkuil@xs4all.nl> wrote:

> > tda9840 support is provided by tda9840.ko, but there's no
> > request_module() or any other reference (except for the above comment) to
> > it at bttv driver. I believe that this is not an isolated case.
> 
> The tda9840 is handled by tvaudio. Other than tda9875 and msp3400 all these 
> audio variants are all handled by that module. tvaudio was developed at the 
> time as a sort of 'catch-all' module and is currently only used by bttv.
> 
> If you look at the code you'll se that tda9840.c can only be used with 
> saa7146, ditto tea6420.c. So these give no conflicts.

Ok.

> > I suspect that there are other cases where no doc is provided on kernel
> > and the only source of information is provided by googling at the net or
> > by taking a look on each card at bttv-gallery to see what chips are
> > inside of each bttv board.
> >
> > So, at least for bttv, IMO, we should: do an i2c scan, on bttv driver,
> > for tvaudio and the other audio modules. If found, then we load the
> > proper driver.
> >
> > We'll still have another problem: There are conflicting addresses. For
> > example, address 0xb0 (8bit notation) is used on tvaudio for tda9874 and
> > on tda9875. I have no idea what boards need tvaudio and what boards need
> > tda9875 module. So, simply probing for 0xb0 won't be enough.
> 
> Luckily the two chips can be told apart from one another. Suggestion: move 
> the support for tda9874 from tvaudio.c to tda9875.c and let that one handle 
> both. They are very similar and that shouldn't be difficult. That will 
> solve this conflict in an elegant manner.
> 
> I see one more conflict between msp3400 and tea6300. It should be possible 
> to implement i2c detect support in msp3400 since that chip can detect what 
> chip it is, and if no msp3400 is found after all we fall back to tvaudio.

Seems the better solution for me also.

> > During the conversion of bttv to V4L2, I've mapped the i2c addresses of
> > the audio modules I found at:
> >
> > 	linux/include/media/i2c-addr.h
> >
> > For cx88, the issue is simpler, since cx88 has its own audio decoder. I
> > dunno why some PV boards have a separate audio processor[1]. Anyway, for
> > cx88, we can add the autodetection code just for that device, and just
> > for tvaudio.
> 
> Are you sure cx88 requires that tvaudio is loaded for some cards? There is 
> no mention about tvaudio and cx88 anywhere, neither source nor 
> documentation, nor google for that matter.

Yes, I'm sure. It were reported by one user at #v4l irc channel. I think some
emails were exchanged also (not sure if they were in priv or not). On that
time, I asked him to submit a patch creating a separate entry for that PV
variant, but he didn't. After some time, we lost contact with him.

> > This will be great, provided that we can do the autoprobing for the audio
> > modules as required by a few drivers like bttv.
> 
> You cannot expect that a user can modprobe an i2c driver and it will 
> magically appear. That's going away. You can change the driver so that it 
> will load the module and let it probe for a series of i2c addresses. There 
> is also an option to let the i2c driver do additional checks (Jean knows 
> more about the details).

We need one solution. For sure it is better if the i2c adapter to do such probing.

Cheers,
Mauro

Re: Minimum kernel version supported by v4l-dvb

[Mauro Carvalho Chehab]

On Sat, 21 Feb 2009 04:06:53 -0800 (PST)
Trent Piepho <xyzzy@speakeasy.org> wrote:

> On Fri, 20 Feb 2009, Mauro Carvalho Chehab wrote:
> > On Sat, 21 Feb 2009 02:12:53 +0100
> > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > > I think that maybe we'll need some legacy-like support for bttv and cx88,
> > > > since there are some boards that relies on the old i2c method to work. On
> > > > those boards (like cx88 Pixelview), the same board model (and PCB
> > > > revision) may or may not have a separate audio decoder. On those devices
> > > > that have an audio decoder, the widely used solution is to load tvaudio
> > > > module and let it bind at the i2c bus, on such cases.
> > >
> > > That's what the i2c_new_probed_device() call is for (called through
> > > v4l2_i2c_new_probed_subdev). You pass a list of i2c addresses that the i2c
> > > core will probe for you: but this comes from the adapter driver, not from
> > > the i2c module.
> >
> > This is a problem. The current procedure used by end users will stop working.
> > It is a little worse: as the adapter driver has no means to know that some
> > device could need tvaudio or other similar devices, we would need some hacking
> > to allow the user to pass a parameter to the driver in order to test/load such
> > drivers, since there's no documentation of when such things are needed.
> 
> The new i2c driver interface also supports a ->detect() method and a list
> of address_data to use it with.  This is much more like the legacy model
> than using i2c_new_probed_device().
> 
> I think a compatability layer than implements attach_adapter,
> detach_adapter, and detach_client using a new-style driver's detect, probe,
> remove, and address_data should not be that hard.
> 
> > > But v4l2-i2c-drv.h is bad enough, and even worse is what it looks like in
> > > the kernel when the compat code has been stripped from it: it's turned into
> > > a completely pointless header. And all the v4l2 i2c modules look peculiar
> > > as well due to that header include.
> 
> As I've said before, the v4l2-i2c headers are lot more complicated than
> they need to be.  I have a tree that's shrunk them greatly.  I don't think
> it's fair to give the current headers as an example of how complicated i2c
> backward compat _must_ be.

We can use your tree as a starting point to review the i2c headers. If they
make no sense for upstream, we should get rid of them, maybe adding it for
removal, just like we do with compat.h at gentree.pl.

Where is the tree? Is it updated to work with the current -tip? Probably, some
merging conflicts would be required, due to Hans trees that weren't yet merged. 

> > This way, the development code won't have any #if's or compat code. I'm afraid
> > that just using patches may also bring another range of troubles of needing to
> > periodically maintain the backports. On the other hand, a syntax/semantic
> > parser would be much more complex to develop.
> 
> IMHO, the ALSA method of providing a backward compatability package is much
> inferior to the way v4l-dvb is doings thing.

I never carefully checked how ALSA actually implemented. The way we do in V4L
provides very few maintainership after a backport is done, with the exception
of i2c backport, where part of the backport code went upstream.

Cheers,
Mauro

Re: Minimum kernel version supported by v4l-dvb

[Jean Delvare]

Hi Trent,

On Sat, 21 Feb 2009 04:06:53 -0800 (PST), Trent Piepho wrote:
> On Fri, 20 Feb 2009, Mauro Carvalho Chehab wrote:
> > On Sat, 21 Feb 2009 02:12:53 +0100
> > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > That's what the i2c_new_probed_device() call is for (called through
> > > v4l2_i2c_new_probed_subdev). You pass a list of i2c addresses that the i2c
> > > core will probe for you: but this comes from the adapter driver, not from
> > > the i2c module.
> >
> > This is a problem. The current procedure used by end users will stop working.
> > It is a little worse: as the adapter driver has no means to know that some
> > device could need tvaudio or other similar devices, we would need some hacking
> > to allow the user to pass a parameter to the driver in order to test/load such
> > drivers, since there's no documentation of when such things are needed.
> 
> The new i2c driver interface also supports a ->detect() method and a list
> of address_data to use it with.  This is much more like the legacy model
> than using i2c_new_probed_device().

Correct.

> I think a compatability layer than implements attach_adapter,
> detach_adapter, and detach_client using a new-style driver's detect, probe,
> remove, and address_data should not be that hard.

Well, that's basically what Hans has been doing with
v4l2-i2c-drv-legacy.h for months now, isn't it? This is the easy part
(even though even this wasn't exactly trivial...)

The hard part is when you want to use pure new-style i2c binding (using
i2c_new_device() or i2c_new_probed_device()) in the upstream kernel.
There is simply no equivalent in pre-2.6.22 kernels. So no matter what
amount of compatibility code you add (and it would get _a lot_ of
compatibility code to get there), at best you will get a different
behavior between new and old kernels, worst case the driver will simply
not work in old kernels.

> > > But v4l2-i2c-drv.h is bad enough, and even worse is what it looks like in
> > > the kernel when the compat code has been stripped from it: it's turned into
> > > a completely pointless header. And all the v4l2 i2c modules look peculiar
> > > as well due to that header include.
> 
> As I've said before, the v4l2-i2c headers are lot more complicated than
> they need to be.  I have a tree that's shrunk them greatly.  I don't think
> it's fair to give the current headers as an example of how complicated i2c
> backward compat _must_ be.

Well, why don't send your patches out to Hans and myself for review? If
you came up with simplifications that work, we will be very happy to
apply them.

Thanks,
-- 
Jean Delvare

Re: Minimum kernel version supported by v4l-dvb

[Hans Verkuil]

On Saturday 21 February 2009 14:11:30 Jean Delvare wrote:
> Hi Trent,
>
> On Sat, 21 Feb 2009 04:06:53 -0800 (PST), Trent Piepho wrote:
> > On Fri, 20 Feb 2009, Mauro Carvalho Chehab wrote:
> > > On Sat, 21 Feb 2009 02:12:53 +0100
> > >
> > > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > > That's what the i2c_new_probed_device() call is for (called through
> > > > v4l2_i2c_new_probed_subdev). You pass a list of i2c addresses that
> > > > the i2c core will probe for you: but this comes from the adapter
> > > > driver, not from the i2c module.
> > >
> > > This is a problem. The current procedure used by end users will stop
> > > working. It is a little worse: as the adapter driver has no means to
> > > know that some device could need tvaudio or other similar devices, we
> > > would need some hacking to allow the user to pass a parameter to the
> > > driver in order to test/load such drivers, since there's no
> > > documentation of when such things are needed.
> >
> > The new i2c driver interface also supports a ->detect() method and a
> > list of address_data to use it with.  This is much more like the legacy
> > model than using i2c_new_probed_device().
>
> Correct.
>
> > I think a compatability layer than implements attach_adapter,
> > detach_adapter, and detach_client using a new-style driver's detect,
> > probe, remove, and address_data should not be that hard.
>
> Well, that's basically what Hans has been doing with
> v4l2-i2c-drv-legacy.h for months now, isn't it? This is the easy part
> (even though even this wasn't exactly trivial...)

Sorry, that's not quite true. v4l2-i2c-drv-legacy.h is for i2c modules that 
are either called new-style (by converted adapter drivers) or old-style (by 
not-yet converted adapter drivers). It does that by creating two i2c_driver 
instances, one for each variant. By contrast, i2c modules that include 
v4l2-i2c-drv.h can only be called by converted adapter drivers. This has 
nothing to do with detect(). I'm not using that at all.

It was always the intention that the legacy.h header would disappear once 
all adapter drivers are converted. But v4l2-i2c-drv.h still has to support 
kernels < 2.6.22 were the new API doesn't exist at all. That's the sticking 
point that prevents us from dropping this header as well and go back to a 
normally written i2c module without all this nonsense.

You may have meant the same thing, Jean, but I thought I should clarify it 
yet a bit more :-)

> The hard part is when you want to use pure new-style i2c binding (using
> i2c_new_device() or i2c_new_probed_device()) in the upstream kernel.
> There is simply no equivalent in pre-2.6.22 kernels. So no matter what
> amount of compatibility code you add (and it would get _a lot_ of
> compatibility code to get there), at best you will get a different
> behavior between new and old kernels, worst case the driver will simply
> not work in old kernels.
>
> > > > But v4l2-i2c-drv.h is bad enough, and even worse is what it looks
> > > > like in the kernel when the compat code has been stripped from it:
> > > > it's turned into a completely pointless header. And all the v4l2
> > > > i2c modules look peculiar as well due to that header include.
> >
> > As I've said before, the v4l2-i2c headers are lot more complicated than
> > they need to be.  I have a tree that's shrunk them greatly.  I don't
> > think it's fair to give the current headers as an example of how
> > complicated i2c backward compat _must_ be.
>
> Well, why don't send your patches out to Hans and myself for review? If
> you came up with simplifications that work, we will be very happy to
> apply them.

The point is not how easy or complicated these headers are, the point is 
that we shouldn't have them at all since they make no sense in the upstream 
kernel.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Minimum kernel version supported by v4l-dvb

[Jean Delvare]

On Sat, 21 Feb 2009 14:28:31 +0100, Hans Verkuil wrote:
> On Saturday 21 February 2009 14:11:30 Jean Delvare wrote:
> > Well, that's basically what Hans has been doing with
> > v4l2-i2c-drv-legacy.h for months now, isn't it? This is the easy part
> > (even though even this wasn't exactly trivial...)
> 
> Sorry, that's not quite true. v4l2-i2c-drv-legacy.h is for i2c modules that 
> are either called new-style (by converted adapter drivers) or old-style (by 
> not-yet converted adapter drivers). It does that by creating two i2c_driver 
> instances, one for each variant. By contrast, i2c modules that include 
> v4l2-i2c-drv.h can only be called by converted adapter drivers. This has 
> nothing to do with detect(). I'm not using that at all.
> 
> It was always the intention that the legacy.h header would disappear once 
> all adapter drivers are converted. But v4l2-i2c-drv.h still has to support 
> kernels < 2.6.22 were the new API doesn't exist at all. That's the sticking 
> point that prevents us from dropping this header as well and go back to a 
> normally written i2c module without all this nonsense.
> 
> You may have meant the same thing, Jean, but I thought I should clarify it 
> yet a bit more :-)

Thanks for the clarification. This just shows one thing: this
compatibility layer has become so complex that even I lose track of what
is what...

> (...)
> The point is not how easy or complicated these headers are, the point is 
> that we shouldn't have them at all since they make no sense in the upstream 
> kernel.

True...

-- 
Jean Delvare

Re: Minimum kernel version supported by v4l-dvb

[Trent Piepho]

On Sat, 21 Feb 2009, Jean Delvare wrote:
> On Sat, 21 Feb 2009 04:06:53 -0800 (PST), Trent Piepho wrote:
> > The new i2c driver interface also supports a ->detect() method and a list
> > of address_data to use it with.  This is much more like the legacy model
> > than using i2c_new_probed_device().
>
> Correct.
>
> > I think a compatability layer than implements attach_adapter,
> > detach_adapter, and detach_client using a new-style driver's detect, probe,
> > remove, and address_data should not be that hard.
>
> Well, that's basically what Hans has been doing with
> v4l2-i2c-drv-legacy.h for months now, isn't it? This is the easy part
> (even though even this wasn't exactly trivial...)

Last time I looked they didn't do this.  They just allowed an i2c driver to
provide both an old-style interface and a probe/remove interface (not
detect, it wasn't around yet).  I think it should be possible for a driver
to provide a probe/remove/detect interface and work on old kernels with a
compat layer than translates the old inform methods into the new methods.


> The hard part is when you want to use pure new-style i2c binding (using
> i2c_new_device() or i2c_new_probed_device()) in the upstream kernel.
> There is simply no equivalent in pre-2.6.22 kernels. So no matter what

Yes, that's the part that seems most difficult.  But maybe it doesn't have
to be such a problem?  If someone writes a new driver and only wants to use
i2c_new_device() style attachment, then they can just use the existing
version system to mark it as 2.6.22+ or 2.6.26+ only.  Don't provide
backward compatibility for the driver and just avoid the problem.  Just
because some new embedded camera doesn't work on 2.6.18 doesn't mean
everyone has to lose 2.6.18 support.

Of course there are the existing drivers like tvaudio and bttv.  In this
case, regardless of compatibility concerns, maybe switching to entirely
i2c_new_device() style attachment isn't the right thing to do?  After all,
if ->detect() should never be used, why is it there and why do sensor
drivers use it?  Don't the myriad versions of tvcards with their various i2c
chips attached seemingly at random have a lot in common with motherboards
and sensor chips?

Re: Minimum kernel version supported by v4l-dvb

[Jean Delvare]

On Sat, 21 Feb 2009 13:45:40 +0100, Hans Verkuil wrote:
> On Saturday 21 February 2009 12:58:01 Mauro Carvalho Chehab wrote:
> > On Sat, 21 Feb 2009 08:28:50 +0100
> > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > OK, once more: there are two types of legacy code: one is that drivers
> > > have to be switched to use the new i2c API. That's what I've been
> > > working on all these months since Plumbers 2008. When all drivers that
> > > use i2c modules have been converted, then we can drop
> > > v4l2-i2c-drv-legacy.h and Jean can drop the autoprobing code in the i2c
> > > core.
> >
> > This will be great, provided that we can do the autoprobing for the audio
> > modules as required by a few drivers like bttv.
> 
> You cannot expect that a user can modprobe an i2c driver and it will 
> magically appear. That's going away. You can change the driver so that it 
> will load the module and let it probe for a series of i2c addresses. There 
> is also an option to let the i2c driver do additional checks (Jean knows 
> more about the details).

Actually with the new I2C binding model, you have quite a few options
depending of what you know and what you need.

* If you know that a given chip is at a given address, you call
  i2c_new_device() from the adapter driver's code.

* If you know a given chip is there but don't know the exact address,
  or if the chip may or may not be there, you call
  i2c_new_probed_device() from the adapter driver's code.

* If you know a given chip is there but don't know the address, or if
  the chip may or may not be there, and the device in question can be
  detected (ID registers you can read), you implement the detect()
  method in the I2C chip driver, which will test a number of addresses
  to find out if a supported chip is there or not. In the adapter driver,
  you define an I2C bus class (e.g. I2C_CLASS_TV_ANALOG) to allow the
  I2C chip driver to probe that specific bus.

* An alternative approach, if letting the I2C chip driver probe for the
  device is too dangerous, is to add custom detection code to the adapter
  driver. Imagine that different versions of the adapter have either
  I2C chip A or chip B at a given address, and the only way to
  differentiate is to write to a given register and read a value back
  from the chip. You can't do that on all I2C buses (writing to
  arbitrary registers is bad) but you can do it on your specific
  adapter. Depending on the result you then call i2c_new_device(A) or
  i2c_new_device(B).

The 3rd method is very similar to the legacy i2c binding model.

-- 
Jean Delvare

Re: Minimum kernel version supported by v4l-dvb

[hermann pitton]

Hi,

just a short confirmation for cx88xx cards with external audio decoders.

Am Samstag, den 21.02.2009, 09:56 -0300 schrieb Mauro Carvalho Chehab:
> On Sat, 21 Feb 2009 13:45:40 +0100
> Hans Verkuil <hverkuil@xs4all.nl> wrote:
> 
> > > tda9840 support is provided by tda9840.ko, but there's no
> > > request_module() or any other reference (except for the above comment) to
> > > it at bttv driver. I believe that this is not an isolated case.
> > 
> > The tda9840 is handled by tvaudio. Other than tda9875 and msp3400 all these 
> > audio variants are all handled by that module. tvaudio was developed at the 
> > time as a sort of 'catch-all' module and is currently only used by bttv.
> > 
> > If you look at the code you'll se that tda9840.c can only be used with 
> > saa7146, ditto tea6420.c. So these give no conflicts.
> 
> Ok.
> 
> > > I suspect that there are other cases where no doc is provided on kernel
> > > and the only source of information is provided by googling at the net or
> > > by taking a look on each card at bttv-gallery to see what chips are
> > > inside of each bttv board.
> > >
> > > So, at least for bttv, IMO, we should: do an i2c scan, on bttv driver,
> > > for tvaudio and the other audio modules. If found, then we load the
> > > proper driver.
> > >
> > > We'll still have another problem: There are conflicting addresses. For
> > > example, address 0xb0 (8bit notation) is used on tvaudio for tda9874 and
> > > on tda9875. I have no idea what boards need tvaudio and what boards need
> > > tda9875 module. So, simply probing for 0xb0 won't be enough.
> > 
> > Luckily the two chips can be told apart from one another. Suggestion: move 
> > the support for tda9874 from tvaudio.c to tda9875.c and let that one handle 
> > both. They are very similar and that shouldn't be difficult. That will 
> > solve this conflict in an elegant manner.
> > 
> > I see one more conflict between msp3400 and tea6300. It should be possible 
> > to implement i2c detect support in msp3400 since that chip can detect what 
> > chip it is, and if no msp3400 is found after all we fall back to tvaudio.
> 
> Seems the better solution for me also.
> 
> > > During the conversion of bttv to V4L2, I've mapped the i2c addresses of
> > > the audio modules I found at:
> > >
> > > 	linux/include/media/i2c-addr.h
> > >
> > > For cx88, the issue is simpler, since cx88 has its own audio decoder. I
> > > dunno why some PV boards have a separate audio processor[1]. Anyway, for
> > > cx88, we can add the autodetection code just for that device, and just
> > > for tvaudio.
> > 
> > Are you sure cx88 requires that tvaudio is loaded for some cards? There is 
> > no mention about tvaudio and cx88 anywhere, neither source nor 
> > documentation, nor google for that matter.
> 
> Yes, I'm sure. It were reported by one user at #v4l irc channel. I think some
> emails were exchanged also (not sure if they were in priv or not). On that
> time, I asked him to submit a patch creating a separate entry for that PV
> variant, but he didn't. After some time, we lost contact with him.

Such cards do exist. Here is one thread.
http://threebit.net/mail-archive/video4linux/msg01432.html

He forgot to attach his patch and finally used the existing card entry
with tvaudio. This user was from Portugal, but later those cards were
also reported from Poland. They came with CX 23880-16 !! and LG
TPI8PSB02, TUNER_LG_PAL_FM (28) with the special radio mode switch 0xa5.

BTW, it is also an explicit design option for saa7134 and saa7133 chips
to use external audio decoders for standards not supported internally,
but I think not used so far.

> > > This will be great, provided that we can do the autoprobing for the audio
> > > modules as required by a few drivers like bttv.
> > 
> > You cannot expect that a user can modprobe an i2c driver and it will 
> > magically appear. That's going away. You can change the driver so that it 
> > will load the module and let it probe for a series of i2c addresses. There 
> > is also an option to let the i2c driver do additional checks (Jean knows 
> > more about the details).
> 
> We need one solution. For sure it is better if the i2c adapter to do such probing.
> 

Cheers,
Hermann

Re: Minimum kernel version supported by v4l-dvb

[kilgota]

On Fri, 20 Feb 2009, Mauro Carvalho Chehab wrote:

> Hi Theodore,
>
> On Fri, 20 Feb 2009 19:30:16 -0600 (CST)
> kilgota@banach.math.auburn.edu wrote:
>
>> Hoping that I can offer some helpful comments on this thread, as someone
>> who came along only in the last couple of months or so:
>>
>> 1. One of the most interesting features which I found in the video for
>> Linux project is the ability to work somewhat independently of the
>> particular kernel version running on the local machine. This is valuable,
>> in the sense that it saves a lot of wasted time and effort just keeping up
>> with which kernel version to use. It was also something which is done so
>> cleverly that at first I could not believe it. Congratulations to those
>> who thought this arrangement up.
>>
>> 2. Sometimes, there is a real problem with a particular version of the
>> kernel which has nothing to do with the task at hand, but it sure can get
>> in the way. As a recent example, soon after starting to work with Adam
>> Baker on the sq905 module (and furthermore having at the time the false
>> impression that the gspca work meant I should be running the latest thing
>> out there) I upgraded from 2.6.27.7 to 2.6.28. Well, there was a rather
>> serious USB bug in 2.6.28. So then _that_ had to be straightened out.
>> Things like that do not promote smooth progress but rather interfere with
>> it.
>>
>> 3. I just bought an eeePC. It is running some 2.6.21.x kernel. My
>> reaction: I do not believe they should be doing that. I would not feel
>> like accommodating them. Comparison: someone wrote to me complaining about
>> problems with libgphoto2-2.1.3, which his distro was still releasing, when
>> libgphoto2-2.3.x was already out and his problem had been solved 24 months
>> before. I told him to upgrade and his problems would go away. He wanted me
>> to fix his old version. I explained that this has been done, and he should
>> avail himself of that by installing a new version. Somewhere there is a
>> line, and that guy crossed it.
>>
>> Trying to put all this together:
>>
>> I think that the semi-independence from the particular kernel-du-jour is a
>> good thing and would seem to me to make progress in the specific area of
>> video to be smoother. Modular or semi-modular development is something
>> nice. One can concentrate on the subject at hand and not on daily kernel
>> upgrading. Nice.
>>
>> I also would not want to bust my butt to support someone's ancient kernel.
>> After all, quite often the reason there is a new kernel version is that
>> some long-undiscovered bug suddenly got discovered. Not all change is
>> just for fun, or just to support new stuff. Some of those bugs had
>> far-reaching consequences, recall. So to support one of the affected
>> kernels involves what, exactly?
>>
>> Hoping that these comments help toward some good conclusion of this issue.
>
> Thank you for your comments.
>
> For sure allowing to compile v4l-dvb with older kernels is very interesting for
> the users. It is not perfect, since a bug upstream will keep affecting the
> backported driver, but, in general, this works well, however, at the cost of
> spending developers time backporting things. Since the size of the tree is
> increasing a lot, we'll likely need to use another solution.

This is not exactly what I was trying to say. I'll try again.

1. Anyone who would call himself a developer will run quite recent kernels 
without being forced to do so, voluntarily and with pleasure.

2. Sometimes the kernel which just came out has a bug. The bug can 
interfere with current work even though it is from another kernel 
subsystem. I mentioned a recent example. The problem was in the basic USB 
area. It specifically related to devices running on alt0 and using a bulk 
endpoint. I was trying to support a camera that streams on alt0 over the 
bulk endpoint. Said bug seriously interfered with progress. Who would say 
that everyone should simultaneously use the same tree, suggests that 
everyone should simultaneously experience the same set of bugs.

3. Because of (2) and for other obvious reasons, the ability to develop 
a kernel subsystem semi-independently of the latest git tree is a clever 
and good thing. Why give it up and tie oneself to just one git tree?

4. If it were my decision, I probably would not tie myself in knots if 
something new would "break" a kernel which is more than a couple of 
versions behind. Right now, this would probably mean I would not care at 
all what happened to people running 2.6.24.x or older. Furthermore, if 
what was "broken" was due to a bug in the old kernel, too bad.

5. So I would continue to allow flexibility but I would not become 
extremely concerned if a kernel more than a couple of versions behind 
would start to have problems. I would try to be nice and let people know, 
unless they started to shout at me, at which point I  would start to 
ignore them.

Probably all of the above would please nobody, and it is a good that I am 
not in charge of anything.

Theodore Kilgore

Re: Minimum kernel version supported by v4l-dvb

[Jean Delvare]

On Sat, 21 Feb 2009 10:42:17 -0600 (CST), kilgota@banach.math.auburn.edu wrote:
> This is not exactly what I was trying to say. I'll try again.
> 
> 1. Anyone who would call himself a developer will run quite recent kernels 
> without being forced to do so, voluntarily and with pleasure.
> 
> 2. Sometimes the kernel which just came out has a bug. The bug can 
> interfere with current work even though it is from another kernel 
> subsystem. I mentioned a recent example. The problem was in the basic USB 
> area. It specifically related to devices running on alt0 and using a bulk 
> endpoint. I was trying to support a camera that streams on alt0 over the 
> bulk endpoint. Said bug seriously interfered with progress. Who would say 
> that everyone should simultaneously use the same tree, suggests that 
> everyone should simultaneously experience the same set of bugs.
> 
> 3. Because of (2) and for other obvious reasons, the ability to develop 
> a kernel subsystem semi-independently of the latest git tree is a clever 
> and good thing. Why give it up and tie oneself to just one git tree?
> 
> 4. If it were my decision, I probably would not tie myself in knots if 
> something new would "break" a kernel which is more than a couple of 
> versions behind. Right now, this would probably mean I would not care at 
> all what happened to people running 2.6.24.x or older. Furthermore, if 
> what was "broken" was due to a bug in the old kernel, too bad.
> 
> 5. So I would continue to allow flexibility but I would not become 
> extremely concerned if a kernel more than a couple of versions behind 
> would start to have problems. I would try to be nice and let people know, 
> unless they started to shout at me, at which point I  would start to 
> ignore them.
> 
> Probably all of the above would please nobody, and it is a good that I am 
> not in charge of anything.

Actually, it would totally please me :)

-- 
Jean Delvare

Re: Minimum kernel version supported by v4l-dvb

[Jean Delvare]

Hi Trent,

On Sat, 21 Feb 2009 05:58:10 -0800 (PST), Trent Piepho wrote:
> On Sat, 21 Feb 2009, Jean Delvare wrote:
> > Well, that's basically what Hans has been doing with
> > v4l2-i2c-drv-legacy.h for months now, isn't it? This is the easy part
> > (even though even this wasn't exactly trivial...)
> 
> Last time I looked they didn't do this.  They just allowed an i2c driver to
> provide both an old-style interface and a probe/remove interface (not
> detect, it wasn't around yet).  I think it should be possible for a driver
> to provide a probe/remove/detect interface and work on old kernels with a
> compat layer than translates the old inform methods into the new methods.

Ah, yes, my bad. Now I remember: I tried to extent Hans' code to add
support for the detect() function, but failed. But maybe someone more
familiar with it (either you or Hans) may succeed where I failed.

> > The hard part is when you want to use pure new-style i2c binding (using
> > i2c_new_device() or i2c_new_probed_device()) in the upstream kernel.
> > There is simply no equivalent in pre-2.6.22 kernels. So no matter what
> 
> Yes, that's the part that seems most difficult.  But maybe it doesn't have
> to be such a problem?  If someone writes a new driver and only wants to use
> i2c_new_device() style attachment, then they can just use the existing
> version system to mark it as 2.6.22+ or 2.6.26+ only.  Don't provide
> backward compatibility for the driver and just avoid the problem.  Just
> because some new embedded camera doesn't work on 2.6.18 doesn't mean
> everyone has to lose 2.6.18 support.

You are right in theory, but in practice there are corner cases where
it isn't that easy. The new binding model wasn't created for my own
fun, it was created because it solves problems. For example, before
Hans converted the zoran driver, i2c chips were sometimes misdetected
when one had several different supported adapters in the same system.
This no longer happens after the conversion. So we are left with two
choices:
* Convert the zoran driver and lose support for kernels < 2.6.22.
* Don't convert the zoran driver and live with the bug forever.
I'd rather go with the first option.

Another example: I am converting the ir-kbd-i2c driver to the new-style
binding model at the moment. This driver was using the legacy binding
model in an unusual way: the addresses being probed depended on the
underlying adapter. This is something the detect() callback in the new
binding model doesn't handle. While you can check for the underlying
adapter in the detect() callback, this happens _after_ the addresses
have been probed. So we could do it, however this would mean probing
all possible addresses on all adapters. As you know, excessive probing
can confuse some chips, so this is quite risky. Using the pure
new-style binding model (no detect()) OTOH fits perfectly.

More generally, the point of the new-style model (without detect()) is
to avoid probes as much as possible. This makes module loading less
risky _and_ significantly faster on some models. Restricting these
benefits to new drivers doesn't sound exactly right.

I guess we're back to the key point I was making in the beginning:
backwards compatibility is nice when it comes at a reasonable price.
When you start degrading the design of the upstream code in order to
make backwards compatibility easier or even possible at all,
something's wrong.

> Of course there are the existing drivers like tvaudio and bttv.  In this
> case, regardless of compatibility concerns, maybe switching to entirely
> i2c_new_device() style attachment isn't the right thing to do?  After all,
> if ->detect() should never be used, why is it there and why do sensor
> drivers use it?  Don't the myriad versions of tvcards with their various i2c
> chips attached seemingly at random have a lot in common with motherboards
> and sensor chips?

You are right, the detect() callback is there to be used in some cases,
and I have no problem with it being used for the bttv driver or any
other v4l driver where it makes sense. But it shouldn't be forgotten
that this approach has roughly the same problems as the legacy model
was, which means that it should ideally only be used when the
alternatives do not work.

Thanks,
-- 
Jean Delvare