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 |
---------------------------------------------------------------------- |