All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@sirena.org.uk>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Kernel Headers Quality Issue
Date: Wed, 12 May 2010 17:53:22 +0100	[thread overview]
Message-ID: <20100512165322.GC4312@sirena.org.uk> (raw)
In-Reply-To: <4BEA448D.5060008@dresearch.de>

On Wed, May 12, 2010 at 08:02:53AM +0200, Steffen Sledz wrote:
> 11.05.2010 16:27, Tom Rini wrote:

> -> autotools report availability of some syscalls (e.g. inotify_init1 or epoll_create1)
> -> apps can use them
> -> if called on older kernels glibc will handle this "gracefully"
> -> fine

> But tests showed that glibc did not handle syscalls this way.

It does but...

> Then you wrote that *every app* itself is responsible to handle syscalls
> which are reported by autotools (linux-libc-headers) as *available* but

...what it does not do is emulate syscalls which are being used by
applications directly.  There are a bunch of kernel features which are
used by glibc internally - for those it will just use fallbacks at
runtime.  For things like epoll which are used directly by applications
it's up to the application to decide if it is willing or able to cope on
older systems.  For many kernel features there's no sane possibility of
emulation.

> are *not available* ? I can't believe that. This sounds absurd for me.

glibc is frequently built for systems other than the one it runs on
(obviously, OE is a big example here) so it needs to support building
against a kernel other than the running one, and there's plenty of cases
even with desktop/server systems where it's useful to be able to link
against features which can't be run (eg, user installs old kernel for a
binary driver, or a vendor wants to distribute a binary which can
optionally use newer features but still run on older systems).



  parent reply	other threads:[~2010-05-12 16:57 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-05  9:36 linux vs. linux-libc-headers? Steffen Sledz
2010-05-05  9:42 ` Graeme Gregory
2010-05-05 10:00   ` Steffen Sledz
2010-05-05 10:05     ` Phil Blundell
2010-05-05 14:50       ` Steffen Sledz
2010-05-06 10:15         ` [PATCH] angstrom-2008.1: use linux-libc-headers 2.6.24 for hipox machine Steffen Sledz
2010-05-06 10:42           ` Koen Kooi
2010-05-06 10:47             ` Steffen Sledz
2010-05-07  6:59               ` Steffen Sledz
2010-05-07  7:23                 ` Koen Kooi
2010-05-07  7:35                   ` Steffen Sledz
2010-05-10  7:36                     ` Steffen Sledz
2010-05-10  8:34                       ` Koen Kooi
2010-05-10 16:46                         ` Tom Rini
2010-05-06 12:03             ` Steffen Sledz
2010-05-07  9:03         ` linux vs. linux-libc-headers? Phil Blundell
2010-05-10  9:15       ` Steffen Sledz
2010-05-12 10:10         ` Phil Blundell
2010-05-10 14:53 ` Kernel Headers Quality Issue (was: linux vs. linux-libc-headers?) Thilo Fromm
2010-05-10 16:55   ` Tom Rini
2010-05-10 19:00     ` Khem Raj
2010-05-14  9:25       ` Kernel Headers Quality Issue Thilo Fromm
2010-05-14 13:05         ` Phil Blundell
2010-05-11  7:19     ` Thilo Fromm
2010-05-10 19:14   ` Kernel Headers Quality Issue (was: linux vs. linux-libc-headers?) Tom Rini
2010-05-11  7:42     ` Kernel Headers Quality Issue Steffen Sledz
2010-05-11 14:27       ` Tom Rini
2010-05-12  6:02         ` Steffen Sledz
2010-05-12 15:23           ` Tom Rini
2010-05-12 16:53           ` Mark Brown [this message]
2010-05-13 11:40           ` Phil Blundell
2010-05-14  9:59             ` Thilo Fromm
2010-05-14 10:25               ` Phil Blundell
2010-05-14 11:40                 ` Thilo Fromm
2010-05-14 12:38                   ` Phil Blundell
2010-05-18  0:14                   ` Mark Brown

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=20100512165322.GC4312@sirena.org.uk \
    --to=broonie@sirena.org.uk \
    --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.