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.