[oe] Distros supporting older kernels?

Steffen Sledz sledz at dresearch-fe.de
Sun Jun 12 09:19:13 UTC 2011


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




More information about the Openembedded-devel mailing list