Re: POLL: for/against dropping support for kernels < 2.6.22

Re: POLL: for/against dropping support for kernels < 2.6.22

[Hans Verkuil]

Hi Trent,

> On Mon, 23 Feb 2009, Jean Delvare wrote:
>> > There are lot's of discussions, but it can be hard sometimes to
>> actually
>> > determine someone's opinion.
>> >
>> > So here is a quick poll, please reply either to the list or directly
>> to me
>> > with your yes/no answer and (optional but welcome) a short explanation
>> to
>> > your standpoint. It doesn't matter if you are a user or developer, I'd
>> like
>> > to see your opinion regardless.
>> >
>> > Please DO NOT reply to the replies, I'll summarize the results in a
>> week's
>> > time and then we can discuss it further.
>> >
>> > Should we drop support for kernels <2.6.22 in our v4l-dvb repository?
>
> Does this mean keep our current system and move the backward compatibility
> point to 2.6.22?
>
> Or not have any backward compatibilty at all?

It was a bit imprecise, perhaps. With 'drop support' I mean in practice
that we:

1) do a one time effort to make everything compile from 2.6.16 onwards
(there are several compile issues right now with older kernels).

2) when it's OK, make a copy of the master repository, call it v4l-dvb-old
or whatever, and people who are still on old kernels can use that to at
least have the possibility to get something newer. We might even do the
occasional update if some important bug is found.

3) strip our master repository from any compatibility code needed to
support the pre-2.6.22 kernels and continue development based on that
code.

We still need to support kernels from 2.6.22 onwards. Although I think the
minimum supported kernel is something that needs a regular sanity check,
right now there are no technical reasons that I am aware of to go to
something newer than 2.6.22.

Whether we keep our current system or not is a separate discussion:
whatever development system you choose there will be work involved in
keeping up the backwards compatibility.

Hope this explains it,

          Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Question regarding detail in dropping support for kernels < 2.6.22 (related to Re: POLL: for/against dropping support for kernels < 2.6.22)

[Tobias Stoeber]

Hello Hans,

Hans Verkuil schrieb:
> We still need to support kernels from 2.6.22 onwards. Although I think the
> minimum supported kernel is something that needs a regular sanity check,
> right now there are no technical reasons that I am aware of to go to
> something newer than 2.6.22.
> 
> Whether we keep our current system or not is a separate discussion:
> whatever development system you choose there will be work involved in
> keeping up the backwards compatibility.

Just out of deep interesst:

Could you, Hans (or anyone else) just explain, what is / are the reason 
to draw the line between kernels 2.6.21 and 2.6.22?

What was the fundamental change there and do these changes as such apply 
to every supported device / driver?

As I understand you, although you drop backport efforts for kernels 
below 2.6.22, you are going to adopt an policy to - in a sense - waste 
development efforts / time on seven instead of 12 kernels?

Wouldn't it then not be more logical to support only the recent kernel 
and the kernel before, becaus in some month time 2.6.30 might include a 
major change which would force you to drop support for < 2.6.29 altogether?

Thanks for your patience and reply,

best regards, Tobias

Re: Question regarding detail in dropping support for kernels < 2.6.22 (related to Re: POLL: for/against dropping support for kernels < 2.6.22)

[Hans Verkuil]

> Hello Hans,
>
> Hans Verkuil schrieb:
>> We still need to support kernels from 2.6.22 onwards. Although I think
>> the
>> minimum supported kernel is something that needs a regular sanity check,
>> right now there are no technical reasons that I am aware of to go to
>> something newer than 2.6.22.
>>
>> Whether we keep our current system or not is a separate discussion:
>> whatever development system you choose there will be work involved in
>> keeping up the backwards compatibility.
>
> Just out of deep interesst:
>
> Could you, Hans (or anyone else) just explain, what is / are the reason
> to draw the line between kernels 2.6.21 and 2.6.22?
>
> What was the fundamental change there and do these changes as such apply
> to every supported device / driver?
>
> As I understand you, although you drop backport efforts for kernels
> below 2.6.22, you are going to adopt an policy to - in a sense - waste
> development efforts / time on seven instead of 12 kernels?
>
> Wouldn't it then not be more logical to support only the recent kernel
> and the kernel before, becaus in some month time 2.6.30 might include a
> major change which would force you to drop support for < 2.6.29
> altogether?
>
> Thanks for your patience and reply,

Hi Tobias,

No problem, I'd be happy to explain.

For a long time whenever you loaded an i2c module the kernel i2c core
would probe all i2c adapters to see if a chip supported by the i2c module
was present. This is very, very bad since the act of probing can corrupt
eeproms and worse. In addition, since many i2c devices cannot be properly
identified, you often get misdetections where the driver thinks it found a
match, when in reality it was a different device altogether.

In kernel 2.6.22 a new i2c API was created that allowed the adapter driver
such as bttv or ivtv to tell the i2c core what i2c devices are on which
address. So a driver that supported the new i2c API would prevent i2c
modules from autoprobing its i2c adapters, and it has to explicitly tell
the i2c code what device is where. It's a bit simplified since there are
still some probing methods available, but in all cases it is the adapter
driver that initiates them. This is a huge improvement and solves many
problems that were previously unsolvable. But it is a totally different
approach where the i2c module no longer initiates probes, but instead it
is done by the adapter driver.

However, it is a big task to convert drivers from the old to the new API.
It requires modifying the i2c modules to support the new API, but as long
as such modules are also still in use by unconverted adapter drivers they
have to support the old API as well. And before you can convert an adapter
driver *all* i2c modules it uses need to be converted to support the new
API.

In addition, since kernels older than 2.6.22 do not support the new API at
all, we need to keep support for the old API around under #if
KERNEL_VERSION as well.

To make all this possible without creating i2c modules riddled with #if's
I created two headers that hide most of this complexity. However, these
headers are exposed in the upstream kernel where they look really weird
when they are stripped from all #ifs.

Now all this is fine as long as adapter drivers exist that are not yet
converted, since that means we need to keep the compat stuff around
anyway. But I'm now attempting to finally convert the last drivers,
hopefully before the 2.6.30 merge window will close. Once that is done,
the only reason left to keep the compat code around is to support
pre-2.6.22 kernels.

It's a lot of tricky code meant primarily to support the transition from
the old to new i2c API. Now that we have almost finished this transition I
think it is time to say goodbye to all the code needed to keep the old i2c
API alive. And that means effectively dropping support for kernels older
than 2.6.22.

Of course, I might not be able to finish the conversion in time for
2.6.30, in which case the compat code needs to stay around for another
kernel cycle.

Luckily, such major API redesigns are rare. And normally the effort needed
to keep compatibility is fairly limited and the additional test exposure
is very welcome. So there are good reasons for having backwards
compatibility. I didn't create the daily build system to verify that it
still compiles on older kernels for nothing. But there are limits to the
amount of effort that I am willing to spend on it. And in this case I
think it's time to drop the compatibility with the old i2c API entirely.

A long and technical story, but I hope it helps explain the background.

Regards,

          Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG