Distros supporting older kernels?

Distros supporting older kernels?

[Steffen Sledz]

Hi Distro Maintainers,

as you could read in earlier messages of mine, we're forced to use an older kernel version (2.6.24) for our hardware. This brings a lot of problems as you can imagine (e.g. we're also bound to udev-141).

Until now we've used angstrom-2008.1 with some own patches according to the linux-libc-headers and udev versions for our hardware which were reasonably not accepted by the Angstrom maintainers (see discussions [1] or [2]).

In there current situation (angstrom-2008.1 is deprecated, the new layer concept will come up) we're looking for a new, better, less hacky solution.

My first question therefor is if there are any distros explicitely supporting older kernels (pre 2.6.27) yet? Or are willing to work on it?

[1] <http://thread.gmane.org/gmane.comp.handhelds.openembedded/32375>
[2] <http://thread.gmane.org/gmane.comp.handhelds.openembedded/42628>

Thx,
Steffen

PS: Does anybody know a good overview which Linux Kernel API changes were made in which kernel version?

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: Distros supporting older kernels?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09-06-11 15:02, Steffen Sledz wrote:
> Hi Distro Maintainers,
> 
> as you could read in earlier messages of mine, we're forced to use an
> older kernel version (2.6.24) for our hardware. This brings a lot of
> problems as you can imagine (e.g. we're also bound to udev-141).
> 
> Until now we've used angstrom-2008.1 with some own patches according to
> the linux-libc-headers and udev versions for our hardware which were
> reasonably not accepted by the Angstrom maintainers (see discussions [1]
> or [2]).
> 
> In there current situation (angstrom-2008.1 is deprecated,

Ehm, 2008.1 is not deprecated, it's still fully supported in the 2011.03
maintenance branch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFN8MbPMkyGM64RGpERAgF7AKCGjnsrW63s4rBTAH/ZUVzFAGbRWACeM/Kc
Bc88jtYjU/yuLsJ3Knh9KLc=
=gpMW
-----END PGP SIGNATURE-----

Re: Distros supporting older kernels?

[Steffen Sledz]

On 09.06.2011 15:12, Koen Kooi wrote:
>> In there current situation (angstrom-2008.1 is deprecated,
>
> Ehm, 2008.1 is not deprecated, it's still fully supported in the 2011.03
> maintenance branch.

OK, you're right. Sorry.

But i think it's still a good reason to look for a better solution.

BTW: Would it be a good idea to create a little overwiew page (in the wiki?) where we can list all the distros using OE with their targets, requirements, limitations, ...?

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: Distros supporting older kernels?

[Khem Raj]

On 06/09/2011 06:02 AM, Steffen Sledz wrote:
> Hi Distro Maintainers,
>
> as you could read in earlier messages of mine, we're forced to use an
> older kernel version (2.6.24) for our hardware. This brings a lot of
> problems as you can imagine (e.g. we're also bound to udev-141).
>
> Until now we've used angstrom-2008.1 with some own patches according to
> the linux-libc-headers and udev versions for our hardware which were
> reasonably not accepted by the Angstrom maintainers (see discussions [1]
> or [2]).
>
> In there current situation (angstrom-2008.1 is deprecated, the new layer
> concept will come up) we're looking for a new, better, less hacky solution.
>
> My first question therefor is if there are any distros explicitely
> supporting older kernels (pre 2.6.27) yet? Or are willing to work on it?
>

I guess a machine layer on top of oe-core could be something you can 
work out and add/override needed recipes in this layer.

> [1] <http://thread.gmane.org/gmane.comp.handhelds.openembedded/32375>
> [2] <http://thread.gmane.org/gmane.comp.handhelds.openembedded/42628>
>
> Thx,
> Steffen
>
> PS: Does anybody know a good overview which Linux Kernel API changes
> were made in which kernel version?
>

Re: Distros supporting older kernels?

[Steffen Sledz]

On 10.06.2011 00:43, Khem Raj wrote:
> On 06/09/2011 06:02 AM, Steffen Sledz wrote:
>> Hi Distro Maintainers,
>>
>> as you could read in earlier messages of mine, we're forced to use an
>> older kernel version (2.6.24) for our hardware. This brings a lot of
>> problems as you can imagine (e.g. we're also bound to udev-141).
>>
>> Until now we've used angstrom-2008.1 with some own patches according to
>> the linux-libc-headers and udev versions for our hardware which were
>> reasonably not accepted by the Angstrom maintainers (see discussions [1]
>> or [2]).
>>
>> In there current situation (angstrom-2008.1 is deprecated, the new layer
>> concept will come up) we're looking for a new, better, less hacky solution.
>>
>> My first question therefor is if there are any distros explicitely
>> supporting older kernels (pre 2.6.27) yet? Or are willing to work on it?
>>
>
> I guess a machine layer on top of oe-core could be something you can work out and add/override needed recipes in this layer.

I think it's not that easy.

For kernels prior to 2.6.27 you can't use a lot of core components (e.g. udev with versions higher than 141 or eggdbus) which *a lot of other components* depend on.

The underlying problem are some kernel API functions like inotify_init1 or epoll_create1. Some distros (e.g. Angstrom) use linux-libc-headers 2.6.31 which is higher then 2.6.27 (what in my opinion conflicts with [1]). So there's no chance to detect the mentioned kernel functions correctly at compile time. :(

As a consequence you have to check this in *all* programs at runtime. This is a good wish but hard to realize. E.g. the udev maintainers itself rejected a related patch[2] and say that they are not willing to support older kernel versions.

So in my opinion there are two possible ways:

1. Use only the old supported versions of the components (udev-141 and glib-dbus instead of eggdbus) with all the consequences for other programs.

2. Determine *all* critical kernel functions, look for *all* the places where these are used, and patch them.

Both are a lot more than some override recipes. So i think this needs an own distro with all the maintenance and testing.

Regards,
Steffen

[1] "but a program built against newer kernel headers may not work on an older kernel" <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/make/headers_install.txt;hb=HEAD>
[2] <http://thread.gmane.org/gmane.linux.hotplug.devel/16590>

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: Distros supporting older kernels?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12-06-11 11:19, Steffen Sledz wrote:
> On 10.06.2011 00:43, Khem Raj wrote:
>> On 06/09/2011 06:02 AM, Steffen Sledz wrote:
>>> Hi Distro Maintainers,
>>>
>>> as you could read in earlier messages of mine, we're forced to use an
>>> older kernel version (2.6.24) for our hardware. This brings a lot of
>>> problems as you can imagine (e.g. we're also bound to udev-141).
>>>
>>> Until now we've used angstrom-2008.1 with some own patches according to
>>> the linux-libc-headers and udev versions for our hardware which were
>>> reasonably not accepted by the Angstrom maintainers (see discussions [1]
>>> or [2]).
>>>
>>> In there current situation (angstrom-2008.1 is deprecated, the new layer
>>> concept will come up) we're looking for a new, better, less hacky
>>> solution.
>>>
>>> My first question therefor is if there are any distros explicitely
>>> supporting older kernels (pre 2.6.27) yet? Or are willing to work on it?
>>>
>>
>> I guess a machine layer on top of oe-core could be something you can
>> work out and add/override needed recipes in this layer.
> 
> I think it's not that easy.
> 
> For kernels prior to 2.6.27 you can't use a lot of core components (e.g.
> udev with versions higher than 141 or eggdbus) which *a lot of other
> components* depend on.
> 
> The underlying problem are some kernel API functions like inotify_init1
> or epoll_create1. Some distros (e.g. Angstrom) use linux-libc-headers
> 2.6.31 which is higher then 2.6.27 (what in my opinion conflicts with
> [1]). So there's no chance to detect the mentioned kernel functions
> correctly at compile time. :(
> 
> As a consequence you have to check this in *all* programs at runtime.
> This is a good wish but hard to realize. E.g. the udev maintainers
> itself rejected a related patch[2] and say that they are not willing to
> support older kernel versions.
> 
> So in my opinion there are two possible ways:
> 
> 1. Use only the old supported versions of the components (udev-141 and
> glib-dbus instead of eggdbus) with all the consequences for other programs.
> 
> 2. Determine *all* critical kernel functions, look for *all* the places
> where these are used, and patch them.
> 
> Both are a lot more than some override recipes. So i think this needs an
> own distro with all the maintenance and testing.

3) Cut your losses and update your kernel port. At some point it just
isn't economically feasible aymore to bend userspace against an obsolete
kernel.

I'm still stuck with 2.6.32 at work for a lot of customers, which is
accumulating more and more backports.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFN9KdhMkyGM64RGpERArsBAKCcIqGbU9C7qjirf9YAU4xUBdAKMACfV50G
GOjNf7icEEzOcx81w0N64Uk=
=SMzJ
-----END PGP SIGNATURE-----

Re: Distros supporting older kernels?

[Steffen Sledz]

On 12.06.2011 13:47, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12-06-11 11:19, Steffen Sledz wrote:
>> On 10.06.2011 00:43, Khem Raj wrote:
>>> On 06/09/2011 06:02 AM, Steffen Sledz wrote:
>>>> Hi Distro Maintainers,
>>>>
>>>> as you could read in earlier messages of mine, we're forced to use an
>>>> older kernel version (2.6.24) for our hardware. This brings a lot of
>>>> problems as you can imagine (e.g. we're also bound to udev-141).
>>>>
>>>> Until now we've used angstrom-2008.1 with some own patches according to
>>>> the linux-libc-headers and udev versions for our hardware which were
>>>> reasonably not accepted by the Angstrom maintainers (see discussions [1]
>>>> or [2]).
>>>>
>>>> In there current situation (angstrom-2008.1 is deprecated, the new layer
>>>> concept will come up) we're looking for a new, better, less hacky
>>>> solution.
>>>>
>>>> My first question therefor is if there are any distros explicitely
>>>> supporting older kernels (pre 2.6.27) yet? Or are willing to work on it?
>>>>
>>>
>>> I guess a machine layer on top of oe-core could be something you can
>>> work out and add/override needed recipes in this layer.
>>
>> I think it's not that easy.
>>
>> For kernels prior to 2.6.27 you can't use a lot of core components (e.g.
>> udev with versions higher than 141 or eggdbus) which *a lot of other
>> components* depend on.
>>
>> The underlying problem are some kernel API functions like inotify_init1
>> or epoll_create1. Some distros (e.g. Angstrom) use linux-libc-headers
>> 2.6.31 which is higher then 2.6.27 (what in my opinion conflicts with
>> [1]). So there's no chance to detect the mentioned kernel functions
>> correctly at compile time. :(
>>
>> As a consequence you have to check this in *all* programs at runtime.
>> This is a good wish but hard to realize. E.g. the udev maintainers
>> itself rejected a related patch[2] and say that they are not willing to
>> support older kernel versions.
>>
>> So in my opinion there are two possible ways:
>>
>> 1. Use only the old supported versions of the components (udev-141 and
>> glib-dbus instead of eggdbus) with all the consequences for other programs.
>>
>> 2. Determine *all* critical kernel functions, look for *all* the places
>> where these are used, and patch them.
>>
>> Both are a lot more than some override recipes. So i think this needs an
>> own distro with all the maintenance and testing.
>
> 3) Cut your losses and update your kernel port. At some point it just
> isn't economically feasible aymore to bend userspace against an obsolete
> kernel.

You can believe me, we would like to do nothing more than this.

But unfortunately we got only one big patch of more than 10000 lines against 2.6.24 from the CPU manufacturer (ex Oxford Semiconductors, now PLX Technology).

We do not have the power to split up and port this code to newer kernel versions and the manufacturer is not willing to do it. :(

Regards,
Steffen

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

Re: Distros supporting older kernels?

[Khem Raj]

On 6/14/2011 11:00 PM, Steffen Sledz wrote:
> On 12.06.2011 13:47, Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 12-06-11 11:19, Steffen Sledz wrote:
>>> On 10.06.2011 00:43, Khem Raj wrote:
>>>> On 06/09/2011 06:02 AM, Steffen Sledz wrote:
>>>>> Hi Distro Maintainers,
>>>>>
>>>>> as you could read in earlier messages of mine, we're forced to use an
>>>>> older kernel version (2.6.24) for our hardware. This brings a lot of
>>>>> problems as you can imagine (e.g. we're also bound to udev-141).
>>>>>
>>>>> Until now we've used angstrom-2008.1 with some own patches
>>>>> according to
>>>>> the linux-libc-headers and udev versions for our hardware which were
>>>>> reasonably not accepted by the Angstrom maintainers (see
>>>>> discussions [1]
>>>>> or [2]).
>>>>>
>>>>> In there current situation (angstrom-2008.1 is deprecated, the new
>>>>> layer
>>>>> concept will come up) we're looking for a new, better, less hacky
>>>>> solution.
>>>>>
>>>>> My first question therefor is if there are any distros explicitely
>>>>> supporting older kernels (pre 2.6.27) yet? Or are willing to work
>>>>> on it?
>>>>>
>>>>
>>>> I guess a machine layer on top of oe-core could be something you can
>>>> work out and add/override needed recipes in this layer.
>>>
>>> I think it's not that easy.
>>>
>>> For kernels prior to 2.6.27 you can't use a lot of core components (e.g.
>>> udev with versions higher than 141 or eggdbus) which *a lot of other
>>> components* depend on.
>>>
>>> The underlying problem are some kernel API functions like inotify_init1
>>> or epoll_create1. Some distros (e.g. Angstrom) use linux-libc-headers
>>> 2.6.31 which is higher then 2.6.27 (what in my opinion conflicts with
>>> [1]). So there's no chance to detect the mentioned kernel functions
>>> correctly at compile time. :(
>>>
>>> As a consequence you have to check this in *all* programs at runtime.
>>> This is a good wish but hard to realize. E.g. the udev maintainers
>>> itself rejected a related patch[2] and say that they are not willing to
>>> support older kernel versions.
>>>
>>> So in my opinion there are two possible ways:
>>>
>>> 1. Use only the old supported versions of the components (udev-141 and
>>> glib-dbus instead of eggdbus) with all the consequences for other
>>> programs.
>>>
>>> 2. Determine *all* critical kernel functions, look for *all* the places
>>> where these are used, and patch them.
>>>
>>> Both are a lot more than some override recipes. So i think this needs an
>>> own distro with all the maintenance and testing.
>>
>> 3) Cut your losses and update your kernel port. At some point it just
>> isn't economically feasible aymore to bend userspace against an obsolete
>> kernel.
>
> You can believe me, we would like to do nothing more than this.
>
> But unfortunately we got only one big patch of more than 10000 lines
> against 2.6.24 from the CPU manufacturer (ex Oxford Semiconductors, now
> PLX Technology).
>
> We do not have the power to split up and port this code to newer kernel
> versions and the manufacturer is not willing to do it. :(

Create a linux-libc-headers recipe which builds out of your 2.6.24 
kernel that can fix glibc compatibility and lot other userspace problems
unless some apps really really need new features from kernel. Then you
have to either backport that functionality in kernel or use older 
version of app which does not depend on the new functionality so this
way you can probably have something

If a standard distro should support it or not depends on distro userbase
for that machine
>
> Regards,
> Steffen
>

Re: Distros supporting older kernels?

[Frans Meulenbroeks]

2011/6/12 Steffen Sledz <sledz@dresearch-fe.de>

> On 10.06.2011 00:43, Khem Raj wrote:
>
>> On 06/09/2011 06:02 AM, Steffen Sledz wrote:
>>
>>> Hi Distro Maintainers,
>>>
>>> as you could read in earlier messages of mine, we're forced to use an
>>> older kernel version (2.6.24) for our hardware. This brings a lot of
>>> problems as you can imagine (e.g. we're also bound to udev-141).
>>>
>>> Until now we've used angstrom-2008.1 with some own patches according to
>>> the linux-libc-headers and udev versions for our hardware which were
>>> reasonably not accepted by the Angstrom maintainers (see discussions [1]
>>> or [2]).
>>>
>>> In there current situation (angstrom-2008.1 is deprecated, the new layer
>>> concept will come up) we're looking for a new, better, less hacky
>>> solution.
>>>
>>> My first question therefor is if there are any distros explicitely
>>> supporting older kernels (pre 2.6.27) yet? Or are willing to work on it?
>>>
>>>
>> I guess a machine layer on top of oe-core could be something you can work
>> out and add/override needed recipes in this layer.
>>
>
> I think it's not that easy.
>
> For kernels prior to 2.6.27 you can't use a lot of core components (e.g.
> udev with versions higher than 141 or eggdbus) which *a lot of other
> components* depend on.
>
> The underlying problem are some kernel API functions like inotify_init1 or
> epoll_create1. Some distros (e.g. Angstrom) use linux-libc-headers 2.6.31
> which is higher then 2.6.27 (what in my opinion conflicts with [1]). So
> there's no chance to detect the mentioned kernel functions correctly at
> compile time. :(
>
> As a consequence you have to check this in *all* programs at runtime. This
> is a good wish but hard to realize. E.g. the udev maintainers itself
> rejected a related patch[2] and say that they are not willing to support
> older kernel versions.
>
> So in my opinion there are two possible ways:
>
> 1. Use only the old supported versions of the components (udev-141 and
> glib-dbus instead of eggdbus) with all the consequences for other programs.
>
> 2. Determine *all* critical kernel functions, look for *all* the places
> where these are used, and patch them.
>
> Both are a lot more than some override recipes. So i think this needs an
> own distro with all the maintenance and testing.
>
> Regards,
> Steffen
>
> [1] "but a program built against newer kernel headers may not work on an
> older kernel" <
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/make/headers_install.txt;hb=HEAD
> >
> [2] <http://thread.gmane.org/gmane.linux.hotplug.devel/16590>
>
>
> Steffen, I feel it really depends on what you are aiming at. For our
products we typically freeze on a certain version; if there are bugs that
hurt us we either fix them (backporting a patch) or move to a newer version
of that specific recipe (and stick it in a local overlay).

E.g. some of our maintenance is done on a monotone revision that was frozen
a few years ago.
I feel if you have to use an older kernel and have a dedicated image (e.g.
because you are doing a real embedded control system) you might be better
off doing the same.
The newest packages are not necessarily better for you, and typically newer
versions tend not to become smaller (but ofc exceptions exist).

Frans