| 1 |
* Peter Stuge <peter@×××××.se> schrieb: |
| 2 |
|
| 3 |
> > No, they can't, especially in embedded world. |
| 4 |
> |
| 5 |
> Obviously there is a limit to every definition of stable. But it is |
| 6 |
> my impression that Linux does not change API at a whim. |
| 7 |
|
| 8 |
True. But there are cases where old APIs/ABIs cease to exist |
| 9 |
(eg. binaries built for 2.6.19 wont run on current kernels anymore). |
| 10 |
|
| 11 |
In embedded world it often becomes even trickier: kernels tend to |
| 12 |
have certain vendor-specific extensions/interfaces which are too |
| 13 |
bleeding edge to have an stable API/ABI yet. (have several such |
| 14 |
cases in a current project) |
| 15 |
|
| 16 |
> > The biggest problem is certain ill-designed packages which try to |
| 17 |
> > guess something from the *running* system. This can only be solved |
| 18 |
> > in the source. |
| 19 |
> |
| 20 |
> Sure, and this is a problem with individual packages. Not so much |
| 21 |
> with the kernel. The packages can be fixed. |
| 22 |
|
| 23 |
ACK. And the packages *should* be fixed, instead of trying to work |
| 24 |
around in dubious ways (eg. certain autoconf'ed packages which have |
| 25 |
certain fallback defaults in AC_TRY_RUN calls, which are likely to |
| 26 |
be wrong). |
| 27 |
|
| 28 |
> > > Do you have a problem with some package? |
| 29 |
> > |
| 30 |
> > Just from the tip of my head, in recent years: network utils, |
| 31 |
> > drbd, etc, ... |
| 32 |
> |
| 33 |
> Because the recommended API to use was changed, or? |
| 34 |
|
| 35 |
The actual API changed. On DRBD it seems to change quite frequently. |
| 36 |
Had to cope with that in a recent project at a big ISP which used |
| 37 |
DRBD on several thousands of boxes with differing configurations, |
| 38 |
we had to wrappers in front of the DRBD userland tools the right |
| 39 |
version is taken for the running kernel (otherwise we'd have to |
| 40 |
update kernel and userland *together* and cold-reboot immediately, |
| 41 |
which is far from being desirable in enterprise environments). |
| 42 |
|
| 43 |
|
| 44 |
cu |
| 45 |
-- |
| 46 |
---------------------------------------------------------------------- |
| 47 |
Enrico Weigelt, metux IT service -- http://www.metux.de/ |
| 48 |
|
| 49 |
phone: +49 36207 519931 email: weigelt@×××××.de |
| 50 |
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 |
| 51 |
---------------------------------------------------------------------- |
| 52 |
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme |
| 53 |
---------------------------------------------------------------------- |
Archives