From: Gábor Lénárt (lgb_at_lgb.hu)
Date: 2007-09-20 12:35:28
On Thu, Sep 20, 2007 at 10:38:41AM +0300, Marko Mäkelä wrote:
> The "fault" of GNU/Linux, if you like to call it that, is changing
> software interfaces. Microsoft has often managed to keep the ABI
> (application binary interface) backward-compatible, so that you can
> still run very old binaries.
>
> Linux is not too bad either: for the fun of it, I was able to fire up
> one of the first graphical web browsers (NCSA Mosaic, last updated
> in 1994 or so) a couple of years ago.
>
> While the user interfaces of the Linux kernel and the GNU libc have
> remained pretty compatible, the Linux kernel interfaces do change
> even between minor versions. That is why it would be best to have
> drivers inside the official Linux kernel tree. However, that could
> be hard nowadays for projects like OpenCBM, given that the kernel
> development is dominated by commercial companies.
This is a common misunderstanding about the Linux kernel. It has got an API
and even ABI towards the user space called syscall interface, and it's quite
stable and compatible since almost the beginings. The problem here is not
the module/drive "ABI", since there is no such thing for real at all (I
mean, API/ABI is something which is designed to be a constant at least
mostly compatible - in time - stuff)! Unlike some operating systems giving
designed ABI or at least API for drivers Linux does not do that, at its root
it's a classical monolithic design: "drivers" cannot be separated at all
from other parts of the kernel there are no separated "drivers". With
kernels start from 2.0.0, notion of "kernel modules" was introduced. It's
main purpose was the possibility to ship _ALL_ "drivers", etc compiled-in
into the kernel without the need to have waste memory, since kernel modules
can be loaded and unloaded. But it was NOT designed as a 'kernel driver ABI'
or something similar. Loading a kernel module is much more like doing a
run-time linking between object files than defining an ABI/API for external
drivers (eg not in-kernel stuffs, Linux is an open source project it's major
goal was implementing any kernel functionality by a single kernel not from
3rd parties and likes). Sure, you may right that this policy is not too
useful for many people. I only say that it's a very big fault to think that
'Linux can be blamed for rapidly changing kernel (driver/module/etc)
interface'. Linux kernel itself is a _SINGLE_ piece of software and was not
designed for that purpose. Using 3rd "modules", "drivers" was not a goal of
Linux it's only a need of current users of Linux. Linux kernel should be
compatible only with itself, the _ONLY_ designed interface 'from outside' is
the syscall API/ABI.
Your comparsion of ABI compatibility between in Windows or Linux is wrong
however, because kernel module interface in only a linking process or
somewhat similar stuff, most of the "drivers"/"modules" are using deep
in-kernel stuffs, so it's not an interface at all (most functionality can be
compiled as module or into the kernel at kernel configurationt time: this
also indicates that it's only matter of linking time - runtime or compile
time - and not an inteface).
You can blame Linux here - of course - that its goals are not the best. But
for its original goals it's not a fault at all but the desired behaviour!
Sure it's somewhat changing nowdays (and it should be, sure). Please do not
treat my mail as wanting flamewar or something similar though.
--
- Gábor
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.