public inbox for gentoo-embedded@lists.gentoo.org
 help / color / mirror / Atom feed
From: Enrico Weigelt <weigelt@metux.de>
To: gentoo-embedded@lists.gentoo.org
Subject: Re: [gentoo-embedded] Is a compilation depend on the running kernel?
Date: Thu, 30 Dec 2010 12:00:42 +0100	[thread overview]
Message-ID: <20101230110042.GB28981@nibiru.local> (raw)
In-Reply-To: <20101230071340.29763.qmail@stuge.se>

* Peter Stuge <peter@stuge.se> schrieb:

> > No, they can't, especially in embedded world.
> 
> Obviously there is a limit to every definition of stable. But it is
> my impression that Linux does not change API at a whim.

True. But there are cases where old APIs/ABIs cease to exist
(eg. binaries built for 2.6.19 wont run on current kernels anymore).

In embedded world it often becomes even trickier: kernels tend to
have certain vendor-specific extensions/interfaces which are too
bleeding edge to have an stable API/ABI yet. (have several such
cases in a current project)
 
> > The biggest problem is certain ill-designed packages which try to
> > guess something from the *running* system. This can only be solved
> > in the source.
> 
> Sure, and this is a problem with individual packages. Not so much
> with the kernel. The packages can be fixed.

ACK. And the packages *should* be fixed, instead of trying to work
around in dubious ways (eg. certain autoconf'ed packages which have
certain fallback defaults in AC_TRY_RUN calls, which are likely to
be wrong).

> > > Do you have a problem with some package?
> > 
> > Just from the tip of my head, in recent years: network utils,
> > drbd, etc, ...
> 
> Because the recommended API to use was changed, or?

The actual API changed. On DRBD it seems to change quite frequently.
Had to cope with that in a recent project at a big ISP which used
DRBD on several thousands of boxes with differing configurations,
we had to wrappers in front of the DRBD userland tools the right
version is taken for the running kernel (otherwise we'd have to
update kernel and userland *together* and cold-reboot immediately,
which is far from being desirable in enterprise environments).


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------



  reply	other threads:[~2010-12-30 12:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-26 15:46 [gentoo-embedded] Is a compilation depend on the running kernel? Kfir Lavi
2010-12-26 16:49 ` Peter Stuge
2010-12-27 14:43   ` Kfir Lavi
2010-12-30  6:39   ` Enrico Weigelt
2010-12-30  7:13     ` Peter Stuge
2010-12-30 11:00       ` Enrico Weigelt [this message]
2010-12-26 18:46 ` Mike Frysinger
2010-12-30  6:46   ` Enrico Weigelt
2010-12-30  7:14     ` Peter Stuge
2010-12-30 11:05       ` Enrico Weigelt
2010-12-31  5:23     ` Mike Frysinger
2010-12-31 16:16       ` Enrico Weigelt
2010-12-31 17:56         ` Mike Frysinger
2011-01-02 21:43           ` Enrico Weigelt
2011-01-02 23:56             ` Mike Frysinger
2010-12-30  6:35 ` Enrico Weigelt

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=20101230110042.GB28981@nibiru.local \
    --to=weigelt@metux.de \
    --cc=gentoo-embedded@lists.gentoo.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