| Greg Kroah-Hartman | c18f636 | 2006-04-27 14:10:12 -0700 | [diff] [blame] | 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. |