summaryrefslogtreecommitdiff
path: root/Documentation/stable_api_nonsense.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/stable_api_nonsense.txt')
-rw-r--r--Documentation/stable_api_nonsense.txt37
1 files changed, 26 insertions, 11 deletions
diff --git a/Documentation/stable_api_nonsense.txt b/Documentation/stable_api_nonsense.txt
index db3be892afb2..24f5aeecee91 100644
--- a/Documentation/stable_api_nonsense.txt
+++ b/Documentation/stable_api_nonsense.txt
@@ -1,17 +1,26 @@
+.. _stable_api_nonsense:
+
The Linux Kernel Driver Interface
+==================================
+
(all of your questions answered and then some)
Greg Kroah-Hartman <greg@kroah.com>
-This is being written to try to explain why Linux does not have a binary
-kernel interface, nor does it have a stable kernel interface. Please
-realize that this article describes the _in kernel_ interfaces, not the
-kernel to userspace interfaces. The kernel to userspace interface is
-the one that application programs use, the syscall interface. That
-interface is _very_ stable over time, and will not break. I have old
-programs that were built on a pre 0.9something kernel that still work
-just fine on the latest 2.6 kernel release. That interface is the one
-that users and application programmers can count on being stable.
+This is being written to try to explain why Linux **does not have a binary
+kernel interface, nor does it have a stable kernel interface**.
+
+.. note::
+
+ Please realize that this article describes the **in kernel** interfaces, not
+ the kernel to userspace interfaces.
+
+ The kernel to userspace interface is the one that application programs use,
+ the syscall interface. That interface is **very** stable over time, and
+ will not break. I have old programs that were built on a pre 0.9something
+ kernel that still work just fine on the latest 2.6 kernel release.
+ That interface is the one that users and application programmers can count
+ on being stable.
Executive Summary
@@ -33,7 +42,7 @@ to worry about the in-kernel interfaces changing. For the majority of
the world, they neither see this interface, nor do they care about it at
all.
-First off, I'm not going to address _any_ legal issues about closed
+First off, I'm not going to address **any** legal issues about closed
source, hidden source, binary blobs, source wrappers, or any other term
that describes kernel drivers that do not have their source code
released under the GPL. Please consult a lawyer if you have any legal
@@ -51,19 +60,23 @@ Binary Kernel Interface
Assuming that we had a stable kernel source interface for the kernel, a
binary interface would naturally happen too, right? Wrong. Please
consider the following facts about the Linux kernel:
+
- Depending on the version of the C compiler you use, different kernel
data structures will contain different alignment of structures, and
possibly include different functions in different ways (putting
functions inline or not.) The individual function organization
isn't that important, but the different data structure padding is
very important.
+
- Depending on what kernel build options you select, a wide range of
different things can be assumed by the kernel:
+
- different structures can contain different fields
- Some functions may not be implemented at all, (i.e. some locks
compile away to nothing for non-SMP builds.)
- Memory within the kernel can be aligned in different ways,
depending on the build options.
+
- Linux runs on a wide range of different processor architectures.
There is no way that binary drivers from one architecture will run
on another architecture properly.
@@ -105,6 +118,7 @@ As a specific examples of this, the in-kernel USB interfaces have
undergone at least three different reworks over the lifetime of this
subsystem. These reworks were done to address a number of different
issues:
+
- A change from a synchronous model of data streams to an asynchronous
one. This reduced the complexity of a number of drivers and
increased the throughput of all USB drivers such that we are now
@@ -166,6 +180,7 @@ very little effort on your part.
The very good side effects of having your driver in the main kernel tree
are:
+
- The quality of the driver will rise as the maintenance costs (to the
original developer) will decrease.
- Other developers will add features to your driver.
@@ -175,7 +190,7 @@ are:
changes require it.
- The driver automatically gets shipped in all Linux distributions
without having to ask the distros to add it.
-
+
As Linux supports a larger number of different devices "out of the box"
than any other operating system, and it supports these devices on more
different processor architectures than any other operating system, this