diff options
Diffstat (limited to 'Documentation/ABI/README')
-rw-r--r-- | Documentation/ABI/README | 77 |
1 files changed, 77 insertions, 0 deletions
diff --git a/Documentation/ABI/README b/Documentation/ABI/README new file mode 100644 index 000000000000..9feaf16f1617 --- /dev/null +++ b/Documentation/ABI/README | |||
@@ -0,0 +1,77 @@ | |||
1 | This directory attempts to document the ABI between the Linux kernel and | ||
2 | userspace, and the relative stability of these interfaces. Due to the | ||
3 | everchanging nature of Linux, and the differing maturity levels, these | ||
4 | interfaces should be used by userspace programs in different ways. | ||
5 | |||
6 | We have four different levels of ABI stability, as shown by the four | ||
7 | different subdirectories in this location. Interfaces may change levels | ||
8 | of stability according to the rules described below. | ||
9 | |||
10 | The different levels of stability are: | ||
11 | |||
12 | stable/ | ||
13 | This directory documents the interfaces that the developer has | ||
14 | defined to be stable. Userspace programs are free to use these | ||
15 | interfaces with no restrictions, and backward compatibility for | ||
16 | them will be guaranteed for at least 2 years. Most interfaces | ||
17 | (like syscalls) are expected to never change and always be | ||
18 | available. | ||
19 | |||
20 | testing/ | ||
21 | This directory documents interfaces that are felt to be stable, | ||
22 | as the main development of this interface has been completed. | ||
23 | The interface can be changed to add new features, but the | ||
24 | current interface will not break by doing this, unless grave | ||
25 | errors or security problems are found in them. Userspace | ||
26 | programs can start to rely on these interfaces, but they must be | ||
27 | aware of changes that can occur before these interfaces move to | ||
28 | be marked stable. Programs that use these interfaces are | ||
29 | strongly encouraged to add their name to the description of | ||
30 | these interfaces, so that the kernel developers can easily | ||
31 | notify them if any changes occur (see the description of the | ||
32 | layout of the files below for details on how to do this.) | ||
33 | |||
34 | obsolete/ | ||
35 | This directory documents interfaces that are still remaining in | ||
36 | the kernel, but are marked to be removed at some later point in | ||
37 | time. The description of the interface will document the reason | ||
38 | why it is obsolete and when it can be expected to be removed. | ||
39 | The file Documentation/feature-removal-schedule.txt may describe | ||
40 | some of these interfaces, giving a schedule for when they will | ||
41 | be removed. | ||
42 | |||
43 | removed/ | ||
44 | This directory contains a list of the old interfaces that have | ||
45 | been removed from the kernel. | ||
46 | |||
47 | Every file in these directories will contain the following information: | ||
48 | |||
49 | What: Short description of the interface | ||
50 | Date: Date created | ||
51 | KernelVersion: Kernel version this feature first showed up in. | ||
52 | Contact: Primary contact for this interface (may be a mailing list) | ||
53 | Description: Long description of the interface and how to use it. | ||
54 | Users: All users of this interface who wish to be notified when | ||
55 | it changes. This is very important for interfaces in | ||
56 | the "testing" stage, so that kernel developers can work | ||
57 | with userspace developers to ensure that things do not | ||
58 | break in ways that are unacceptable. It is also | ||
59 | important to get feedback for these interfaces to make | ||
60 | sure they are working in a proper way and do not need to | ||
61 | be changed further. | ||
62 | |||
63 | |||
64 | How things move between levels: | ||
65 | |||
66 | Interfaces in stable may move to obsolete, as long as the proper | ||
67 | notification is given. | ||
68 | |||
69 | Interfaces may be removed from obsolete and the kernel as long as the | ||
70 | documented amount of time has gone by. | ||
71 | |||
72 | Interfaces in the testing state can move to the stable state when the | ||
73 | developers feel they are finished. They cannot be removed from the | ||
74 | kernel tree without going through the obsolete state first. | ||
75 | |||
76 | It's up to the developer to place their interfaces in the category they | ||
77 | wish for it to start out in. | ||