From: Michael Jones <michael.jones@matrix-vision.de>
To: openembedded-devel@lists.openembedded.org
Cc: koen@dominion.thruhere.net, openembedded-core@lists.openembedded.org
Subject: Re: [oe] staging & using kernel headers
Date: Wed, 06 Apr 2011 17:47:15 +0200 [thread overview]
Message-ID: <4D9C8B03.8080008@matrix-vision.de> (raw)
In-Reply-To: <1301316136.3018.189.camel@rex>
Sorry for the delay, I overlooked the last 2 replies because I was no
longer in to: or cc: :(
On 03/28/2011 02:42 PM, Richard Purdie wrote:
> On Fri, 2011-03-25 at 17:02 +0100, Michael Jones wrote:
>> On 03/25/2011 03:55 PM, Richard Purdie wrote:
>>> On Fri, 2011-03-25 at 15:14 +0100, Michael Jones wrote:
>>> Ok, so you only really have the options of:
>>>
>>> a) Use a specific patched kernel for linux-libc-headers which has these
>>> headers in it (see below for why this is ugly)
>>> b) Install some extra headers in "libc-headers-extras" type recipe
>>> c) Ship default versions of the headers with your userspace and use
>>> those if shared versions don't exist. This assumes the API is stable and
>>> on its way to mainline.
>>>
>>> I don't think this is as common a requirement as you think as most
>>> people get this kind of thing merged into the mainline kernel to try and
>>> reduce this kind of problem.
>>
>> To clarify, it's not that I have a custom patched kernel I need to use.
>> I am following V4L2 development, so I am using a new kernel from those
>> developers. V4L2 changes do of course move upstream.
>
> Ok, sorry, I was lacking context here.
>
>>> The ugliness is where you have two different arm boards you want to
>>> build, with a common optimisation/toolchain and each wants to redirect
>>> linux-libc-headers to its own "special" version. The question is then,
>>> why aren't the "special" bits in mainline.
>>
>> OK, so here's what I'm realizing, please correct me if I'm wrong:
>> What I did unconventionally (ie. wrong) was to use a kernel version
>> newer than my linux-libc-headers were. I should create a new
>> linux-libc-headers recipe, as I had done with the kernel recipe, and
>> build glibc and linux-libc-headers using my 2.6.38 kernel.
>
> We should *always* be using linux-libc-headers >= to the kernel version
> being used.
Isn't it the other way around? Steffen Sledz had the opposite problem
as me in Feb
(http://www.mail-archive.com/openembedded-devel%40lists.openembedded.org/msg16022.html)
because he's using a kernel older than the linux-libc-headers. He
quotes the kernel doc: "This means that a program built against a C
library using older kernel headers should run on a newer kernel"
>
>> I only stumbled upon this because the gstreamer-ti recipes were pointing
>> at internal kernel headers, but because these are user-space apps, they
>> should actually be using the linux-libc-headers. Right?
>
> Ideally, yes. I know under some circumstances, they might want to poke
> into internal kernel headers but that is really a design issue that
> needs fixing.
>
> Cheers,
>
> Richard
>
-Michael
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
WARNING: multiple messages have this Message-ID (diff)
From: Michael Jones <michael.jones@matrix-vision.de>
To: openembedded-devel@lists.openembedded.org
Cc: koen@dominion.thruhere.net,
Richard Purdie <richard.purdie@linuxfoundation.org>,
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] staging & using kernel headers
Date: Wed, 06 Apr 2011 17:47:15 +0200 [thread overview]
Message-ID: <4D9C8B03.8080008@matrix-vision.de> (raw)
In-Reply-To: <1301316136.3018.189.camel@rex>
Sorry for the delay, I overlooked the last 2 replies because I was no
longer in to: or cc: :(
On 03/28/2011 02:42 PM, Richard Purdie wrote:
> On Fri, 2011-03-25 at 17:02 +0100, Michael Jones wrote:
>> On 03/25/2011 03:55 PM, Richard Purdie wrote:
>>> On Fri, 2011-03-25 at 15:14 +0100, Michael Jones wrote:
>>> Ok, so you only really have the options of:
>>>
>>> a) Use a specific patched kernel for linux-libc-headers which has these
>>> headers in it (see below for why this is ugly)
>>> b) Install some extra headers in "libc-headers-extras" type recipe
>>> c) Ship default versions of the headers with your userspace and use
>>> those if shared versions don't exist. This assumes the API is stable and
>>> on its way to mainline.
>>>
>>> I don't think this is as common a requirement as you think as most
>>> people get this kind of thing merged into the mainline kernel to try and
>>> reduce this kind of problem.
>>
>> To clarify, it's not that I have a custom patched kernel I need to use.
>> I am following V4L2 development, so I am using a new kernel from those
>> developers. V4L2 changes do of course move upstream.
>
> Ok, sorry, I was lacking context here.
>
>>> The ugliness is where you have two different arm boards you want to
>>> build, with a common optimisation/toolchain and each wants to redirect
>>> linux-libc-headers to its own "special" version. The question is then,
>>> why aren't the "special" bits in mainline.
>>
>> OK, so here's what I'm realizing, please correct me if I'm wrong:
>> What I did unconventionally (ie. wrong) was to use a kernel version
>> newer than my linux-libc-headers were. I should create a new
>> linux-libc-headers recipe, as I had done with the kernel recipe, and
>> build glibc and linux-libc-headers using my 2.6.38 kernel.
>
> We should *always* be using linux-libc-headers >= to the kernel version
> being used.
Isn't it the other way around? Steffen Sledz had the opposite problem
as me in Feb
(http://www.mail-archive.com/openembedded-devel%40lists.openembedded.org/msg16022.html)
because he's using a kernel older than the linux-libc-headers. He
quotes the kernel doc: "This means that a program built against a C
library using older kernel headers should run on a newer kernel"
>
>> I only stumbled upon this because the gstreamer-ti recipes were pointing
>> at internal kernel headers, but because these are user-space apps, they
>> should actually be using the linux-libc-headers. Right?
>
> Ideally, yes. I know under some circumstances, they might want to poke
> into internal kernel headers but that is really a design issue that
> needs fixing.
>
> Cheers,
>
> Richard
>
-Michael
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
next prev parent reply other threads:[~2011-04-06 15:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-18 9:49 staging & using kernel headers Michael Jones
2011-03-18 9:55 ` Koen Kooi
2011-03-25 13:38 ` Richard Purdie
2011-03-25 13:38 ` [OE-core] " Richard Purdie
2011-03-25 14:14 ` Michael Jones
2011-03-25 14:14 ` [OE-core] " Michael Jones
2011-03-25 14:55 ` Richard Purdie
2011-03-25 14:55 ` [OE-core] " Richard Purdie
2011-03-25 16:02 ` Michael Jones
2011-03-25 16:02 ` [OE-core] " Michael Jones
2011-03-28 12:42 ` [oe] " Richard Purdie
2011-03-28 12:42 ` [OE-core] " Richard Purdie
2011-03-28 16:39 ` [oe] " Khem Raj
2011-03-28 16:39 ` [OE-core] " Khem Raj
2011-04-07 13:03 ` [oe] " Michael Jones
2011-04-07 13:03 ` [OE-core] " Michael Jones
2011-04-06 15:47 ` Michael Jones [this message]
2011-04-06 15:47 ` Michael Jones
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=4D9C8B03.8080008@matrix-vision.de \
--to=michael.jones@matrix-vision.de \
--cc=koen@dominion.thruhere.net \
--cc=openembedded-core@lists.openembedded.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.