From: Steffen Sledz <sledz@dresearch-fe.de>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Distros supporting older kernels?
Date: Sun, 12 Jun 2011 11:19:13 +0200 [thread overview]
Message-ID: <4DF48491.6070901@dresearch-fe.de> (raw)
In-Reply-To: <4DF14C7E.7000701@gmail.com>
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
next prev parent reply other threads:[~2011-06-12 9:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-09 13:02 Distros supporting older kernels? Steffen Sledz
2011-06-09 13:12 ` Koen Kooi
2011-06-09 13:35 ` Steffen Sledz
2011-06-09 22:43 ` Khem Raj
2011-06-12 9:19 ` Steffen Sledz [this message]
2011-06-12 11:47 ` Koen Kooi
2011-06-15 6:00 ` Steffen Sledz
2011-06-15 14:58 ` Khem Raj
2011-06-12 21:21 ` Frans Meulenbroeks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DF48491.6070901@dresearch-fe.de \
--to=sledz@dresearch-fe.de \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox