78 строки
3.3 KiB
Plaintext
78 строки
3.3 KiB
Plaintext
|
This directory attempts to document the ABI between the Linux kernel and
|
||
|
|
userspace, and the relative stability of these interfaces. Due to the
|
||
|
|
everchanging nature of Linux, and the differing maturity levels, these
|
||
|
|
interfaces should be used by userspace programs in different ways.
|
||
|
|
|
||
|
|
We have four different levels of ABI stability, as shown by the four
|
||
|
|
different subdirectories in this location. Interfaces may change levels
|
||
|
|
of stability according to the rules described below.
|
||
|
|
|
||
|
|
The different levels of stability are:
|
||
|
|
|
||
|
|
stable/
|
||
|
|
This directory documents the interfaces that the developer has
|
||
|
|
defined to be stable. Userspace programs are free to use these
|
||
|
|
interfaces with no restrictions, and backward compatibility for
|
||
|
|
them will be guaranteed for at least 2 years. Most interfaces
|
||
|
|
(like syscalls) are expected to never change and always be
|
||
|
|
available.
|
||
|
|
|
||
|
|
testing/
|
||
|
|
This directory documents interfaces that are felt to be stable,
|
||
|
|
as the main development of this interface has been completed.
|
||
|
|
The interface can be changed to add new features, but the
|
||
|
|
current interface will not break by doing this, unless grave
|
||
|
|
errors or security problems are found in them. Userspace
|
||
|
|
programs can start to rely on these interfaces, but they must be
|
||
|
|
aware of changes that can occur before these interfaces move to
|
||
|
|
be marked stable. Programs that use these interfaces are
|
||
|
|
strongly encouraged to add their name to the description of
|
||
|
|
these interfaces, so that the kernel developers can easily
|
||
|
|
notify them if any changes occur (see the description of the
|
||
|
|
layout of the files below for details on how to do this.)
|
||
|
|
|
||
|
|
obsolete/
|
||
|
|
This directory documents interfaces that are still remaining in
|
||
|
|
the kernel, but are marked to be removed at some later point in
|
||
|
|
time. The description of the interface will document the reason
|
||
|
|
why it is obsolete and when it can be expected to be removed.
|
||
|
|
The file Documentation/feature-removal-schedule.txt may describe
|
||
|
|
some of these interfaces, giving a schedule for when they will
|
||
|
|
be removed.
|
||
|
|
|
||
|
|
removed/
|
||
|
|
This directory contains a list of the old interfaces that have
|
||
|
|
been removed from the kernel.
|
||
|
|
|
||
|
|
Every file in these directories will contain the following information:
|
||
|
|
|
||
|
|
What: Short description of the interface
|
||
|
|
Date: Date created
|
||
|
|
KernelVersion: Kernel version this feature first showed up in.
|
||
|
|
Contact: Primary contact for this interface (may be a mailing list)
|
||
|
|
Description: Long description of the interface and how to use it.
|
||
|
|
Users: All users of this interface who wish to be notified when
|
||
|
|
it changes. This is very important for interfaces in
|
||
|
|
the "testing" stage, so that kernel developers can work
|
||
|
|
with userspace developers to ensure that things do not
|
||
|
|
break in ways that are unacceptable. It is also
|
||
|
|
important to get feedback for these interfaces to make
|
||
|
|
sure they are working in a proper way and do not need to
|
||
|
|
be changed further.
|
||
|
|
|
||
|
|
|
||
|
|
How things move between levels:
|
||
|
|
|
||
|
|
Interfaces in stable may move to obsolete, as long as the proper
|
||
|
|
notification is given.
|
||
|
|
|
||
|
|
Interfaces may be removed from obsolete and the kernel as long as the
|
||
|
|
documented amount of time has gone by.
|
||
|
|
|
||
|
|
Interfaces in the testing state can move to the stable state when the
|
||
|
|
developers feel they are finished. They cannot be removed from the
|
||
|
|
kernel tree without going through the obsolete state first.
|
||
|
|
|
||
|
|
It's up to the developer to place their interfaces in the category they
|
||
|
|
wish for it to start out in.
|