RFC: remove support from v4l-dvb for kernels < 2.6.16

RFC: remove support from v4l-dvb for kernels < 2.6.16

[Hans Verkuil]

RFC: remove support from v4l-dvb for kernels < 2.6.16

After spending some time trying to get v4l-dvb to compile on older 
kernels I discovered that:

- it is OK for kernels >= 2.6.19

- it does not compile at the moment for kernels >= 2.6.16 and < 2.6.19, 
but that this can be fixed.

- that it can be made to compile for kernels >= 2.6.12 and < 2.6.16, 
although quite a few drivers had to be disabled and looking at the type 
of compile warnings emitted the result would likely crash, especially 
the closer one gets to 2.6.12.

- that I no longer can compile against older kernels since gcc-4.1.2 no 
longer accepts some constructions used in those kernel sources.

I propose that we remove the support for kernels < 2.6.16. Kernel 2.6.16 
is the kernel that's being maintained long-term, so that makes it a 
good starting point. I know that I get the occasional question about 
kernel 2v4l/em28xx-audio.c.6.18, so that definitely has to be supported 
by v4l-dvb, and the differences between 2.6.18 and 2.6.16 are minor, so 
extending the support to 2.6.16 is not a problem.

I did a few scans and of the approximately 932 KERNEL_VERSION checks 
only 268 remain if we drop support for anything below 2.6.26. That's a 
major cleanup.

Since it is now simply broken for anything below 2.6.19 I think it is a 
good solution to on the one hand do a major cleanup at the expense of 
making it unlikely that we will ever support kernels below 2.6.16, and 
on the other hand at least start to support 2.6.16 and up.

I can set up a test build to periodically test if v4l-dvb still compiles 
on these older kernels (although currently I can only test on a 32 bit 
Intel platform).

I'm also willing to do the clean up (I've always liked throwing away 
code!).

In the long term we should probably review the minimum kernel 
requirements on a yearly basis and see if we should move it up. 
Especially major changes in the way the kernel handles device structs 
can be a big pain to maintain. That's currently the main reason for the 
breakage of kernels < 2.6.19.

Regards,

	Hans Verkuil

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] RFC: remove support from v4l-dvb for kernels < 2.6.16

[Oliver Endriss]

Hans Verkuil wrote:
> RFC: remove support from v4l-dvb for kernels < 2.6.16
> 
> After spending some time trying to get v4l-dvb to compile on older 
> kernels I discovered that:
> 
> - it is OK for kernels >= 2.6.19
> 
> - it does not compile at the moment for kernels >= 2.6.16 and < 2.6.19, 
> but that this can be fixed.
> 
> - that it can be made to compile for kernels >= 2.6.12 and < 2.6.16, 
> although quite a few drivers had to be disabled and looking at the type 
> of compile warnings emitted the result would likely crash, especially 
> the closer one gets to 2.6.12.
> 
> - that I no longer can compile against older kernels since gcc-4.1.2 no 
> longer accepts some constructions used in those kernel sources.
> 
> I propose that we remove the support for kernels < 2.6.16. Kernel 2.6.16 
> is the kernel that's being maintained long-term, so that makes it a 
> good starting point. I know that I get the occasional question about 
> kernel 2v4l/em28xx-audio.c.6.18, so that definitely has to be supported 
> by v4l-dvb, and the differences between 2.6.18 and 2.6.16 are minor, so 
> extending the support to 2.6.16 is not a problem.
> 
> I did a few scans and of the approximately 932 KERNEL_VERSION checks 
> only 268 remain if we drop support for anything below 2.6.26. That's a 
> major cleanup.
> 
> Since it is now simply broken for anything below 2.6.19 I think it is a 
> good solution to on the one hand do a major cleanup at the expense of 
> making it unlikely that we will ever support kernels below 2.6.16, and 
> on the other hand at least start to support 2.6.16 and up.
> 
> I can set up a test build to periodically test if v4l-dvb still compiles 
> on these older kernels (although currently I can only test on a 32 bit 
> Intel platform).
> 
> I'm also willing to do the clean up (I've always liked throwing away 
> code!).
> 
> In the long term we should probably review the minimum kernel 
> requirements on a yearly basis and see if we should move it up. 
> Especially major changes in the way the kernel handles device structs 
> can be a big pain to maintain. That's currently the main reason for the 
> breakage of kernels < 2.6.19.
> 
> Regards,
> 
> 	Hans Verkuil

Ack, I second that.


CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] RFC: remove support from v4l-dvb for kernels < 2.6.16

[Andy Walls]

On Thu, 2008-07-03 at 23:52 +0200, Hans Verkuil wrote:
> RFC: remove support from v4l-dvb for kernels < 2.6.16
> 
> After spending some time trying to get v4l-dvb to compile on older 
> kernels I discovered that:
> 
> - it is OK for kernels >= 2.6.19
> 
> - it does not compile at the moment for kernels >= 2.6.16 and < 2.6.19, 
> but that this can be fixed.
> 
> - that it can be made to compile for kernels >= 2.6.12 and < 2.6.16, 
> although quite a few drivers had to be disabled and looking at the type 
> of compile warnings emitted the result would likely crash, especially 
> the closer one gets to 2.6.12.
> 
> - that I no longer can compile against older kernels since gcc-4.1.2 no 
> longer accepts some constructions used in those kernel sources.

But a user can have an old kernel version and an old tool chain.  IMO I
don't think gcc's version is a valid criterion, as that makes an
assumption about what the user is using to build his very old kernel.

I know Fedora 5 used to include a gcc-3.2.3 (in the compat-gcc-32
package) for compiling older stuff.  I guess there was a major shift in
gcc after that point.  (I use gcc-3.2.3 in building the x86_64-mips
cross compiler tool chain for building the linux v2.4.20 firmware for my
router.) 


> I did a few scans and of the approximately 932 KERNEL_VERSION checks 
> only 268 remain if we drop support for anything below 2.6.26. That's a 
> major cleanup.

> Since it is now simply broken for anything below 2.6.19 I think it is a 
> good solution to on the one hand do a major cleanup at the expense of 
> making it unlikely that we will ever support kernels below 2.6.16, and 
> on the other hand at least start to support 2.6.16 and up.

Only supporting 2.6.26 onward would prompt a surge of questions
regarding compilation problems for users who are only a few kernel
versions behind.  I think your suggestion of supporting a few kernels
back (2.6.16 or 2.6.19) is preferable.

My $0.02

-Andy

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] RFC: remove support from v4l-dvb for kernels < 2.6.16

[Hans Verkuil]

On Sunday 06 July 2008 14:58:34 Andy Walls wrote:
> On Thu, 2008-07-03 at 23:52 +0200, Hans Verkuil wrote:
> > RFC: remove support from v4l-dvb for kernels < 2.6.16
> >
> > After spending some time trying to get v4l-dvb to compile on older
> > kernels I discovered that:
> >
> > - it is OK for kernels >= 2.6.19
> >
> > - it does not compile at the moment for kernels >= 2.6.16 and <
> > 2.6.19, but that this can be fixed.
> >
> > - that it can be made to compile for kernels >= 2.6.12 and <
> > 2.6.16, although quite a few drivers had to be disabled and looking
> > at the type of compile warnings emitted the result would likely
> > crash, especially the closer one gets to 2.6.12.
> >
> > - that I no longer can compile against older kernels since
> > gcc-4.1.2 no longer accepts some constructions used in those kernel
> > sources.
>
> But a user can have an old kernel version and an old tool chain.  IMO
> I don't think gcc's version is a valid criterion, as that makes an
> assumption about what the user is using to build his very old kernel.

It's not a valid criterium, but the combination with the nasty compile 
warnings I get when compiling for kernels 2.6.12-2.6.15 does make it an 
additional consideration. Not to mention the additional effort required 
to keep it all running.

> I know Fedora 5 used to include a gcc-3.2.3 (in the compat-gcc-32
> package) for compiling older stuff.  I guess there was a major shift
> in gcc after that point.  (I use gcc-3.2.3 in building the
> x86_64-mips cross compiler tool chain for building the linux v2.4.20
> firmware for my router.)
>
> > I did a few scans and of the approximately 932 KERNEL_VERSION
> > checks only 268 remain if we drop support for anything below
> > 2.6.26. That's a major cleanup.
    ^^^^^^

I meant 2.6.16. Sorry, typo.

> >
> > Since it is now simply broken for anything below 2.6.19 I think it
> > is a good solution to on the one hand do a major cleanup at the
> > expense of making it unlikely that we will ever support kernels
> > below 2.6.16, and on the other hand at least start to support
> > 2.6.16 and up.
>
> Only supporting 2.6.26 onward would prompt a surge of questions
> regarding compilation problems for users who are only a few kernel
> versions behind.  I think your suggestion of supporting a few kernels
> back (2.6.16 or 2.6.19) is preferable.
>
> My $0.02
>
> -Andy


Regards,

	Hans

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [linux-dvb] RFC: remove support from v4l-dvb for kernels < 2.6.16

[Thierry Merle]

Hans Verkuil a écrit :
> RFC: remove support from v4l-dvb for kernels < 2.6.16
> 
> After spending some time trying to get v4l-dvb to compile on older 
> kernels I discovered that:
> 
> - it is OK for kernels >= 2.6.19
> 
> - it does not compile at the moment for kernels >= 2.6.16 and < 2.6.19, 
> but that this can be fixed.
> 
> - that it can be made to compile for kernels >= 2.6.12 and < 2.6.16, 
> although quite a few drivers had to be disabled and looking at the type 
> of compile warnings emitted the result would likely crash, especially 
> the closer one gets to 2.6.12.
> 
> - that I no longer can compile against older kernels since gcc-4.1.2 no 
> longer accepts some constructions used in those kernel sources.
> 
gcc 3.2 should compile the 2.6.16 kernel.
> I propose that we remove the support for kernels < 2.6.16. Kernel 2.6.16 
> is the kernel that's being maintained long-term, so that makes it a 
> good starting point. I know that I get the occasional question about 
> kernel 2v4l/em28xx-audio.c.6.18, so that definitely has to be supported 
> by v4l-dvb, and the differences between 2.6.18 and 2.6.16 are minor, so 
> extending the support to 2.6.16 is not a problem.
> 
> I did a few scans and of the approximately 932 KERNEL_VERSION checks 
> only 268 remain if we drop support for anything below 2.6.26. That's a 
> major cleanup.
> 
> Since it is now simply broken for anything below 2.6.19 I think it is a 
> good solution to on the one hand do a major cleanup at the expense of 
> making it unlikely that we will ever support kernels below 2.6.16, and 
> on the other hand at least start to support 2.6.16 and up.
> 
> I can set up a test build to periodically test if v4l-dvb still compiles 
> on these older kernels (although currently I can only test on a 32 bit 
> Intel platform).
> 
> I'm also willing to do the clean up (I've always liked throwing away 
> code!).
Less code, less bugs ;)
> 
> In the long term we should probably review the minimum kernel 
> requirements on a yearly basis and see if we should move it up. 
> Especially major changes in the way the kernel handles device structs 
> can be a big pain to maintain. That's currently the main reason for the 
> breakage of kernels < 2.6.19.
> 
> Regards,
> 
> 	Hans Verkuil
> 
Ack.
We should mention every year on the wiki which mercurial revision compiles on which minimal revision of the kernel and minimal gcc version.
Making support for very old kernels and very old gcc versions induces complex conditional code, indeed. And I doubt a linux device cannot be upgraded to 2.6.16 version or higher.
Except those with binary drivers in it but it is another debate.

If we succeed in making some code factorization/simplification perhaps we would be able to lower the minimal revision of the kernel supported, in a long term...

Regards,
Thierry

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list