patch-2.2.18 linux/Documentation/SubmittingDrivers

• Lines: 113
• Date: Sun Oct 15 21:13:17 2000
• Orig file: v2.2.17/Documentation/SubmittingDrivers
• Orig date: Thu Jan 1 01:00:00 1970

diff -u --new-file --recursive --exclude-from /usr/src/exclude v2.2.17/Documentation/SubmittingDrivers linux/Documentation/SubmittingDrivers
@@ -0,0 +1,112 @@
+Submitting Drivers For The Linux Kernel
+---------------------------------------
+
+This document is intended to explain how to submit device drivers to the
+Linux 2.2 and 2.4test kernel trees. Note that if you are interested in video
+card drivers you should probably talk to XFree86 (http://wwww.xfree86.org) 
+instead.
+
+Allocating Device Numbers
+-------------------------
+
+Major and minor numbers for devices are allocated by the Linux assigned name
+and number authority (currently better known as H Peter Anvin). The
+site is http://www.lanana.org/. This also deals with allocating numbers for
+devices that are not going to be submitted to the mainstream kernel.
+
+If you don't use assigned numbers then when you device is submitted it will
+get given an assigned number even if that is different from values you may
+have shipped to customers before.
+
+Who To Submit Drivers To
+------------------------
+
+Linux 2.0:
+	No new drivers are accepted for this kernel tree
+
+Linux 2.2:
+	If the code area has a general maintainer then please submit it to
+	the maintainer listed in MAINTAINERS in the kernel file. If the
+	maintainer does not respond or you cannot find the appropriate
+	maintainer then please contact Alan Cox <alan@lxorguk.ukuu.org.uk>
+
+Linux 2.4test:
+	This kernel tree is under active development. The same rules apply
+	as 2.2 but you may wish to submit your driver via linux-kernel (see
+	resources) and follow that list to track changes in API's. These
+	should no longer be occuring as we are now in a code freeze.
+	The final contact point for Linux 2.4 submissions is 	
+	<torvalds@transmeta.com>.
+
+What Criteria Determine Acceptance
+----------------------------------
+
+Licensing:	The code must be released to us under the GNU General Public
+		License. We don't insist on any kind of exclusively GPL 
+		licensing, and if you wish the driver to be useful to other 
+		communities such as BSD you may well wish to release under 
+		multiple licenses.
+
+Interfaces:	If your driver uses existing interfaces and behaves like
+		other drivers in the same class it will be much more likely
+		to be accepted than if it invents gratuitous new ones. 
+		If you need to implement a common API over Linux and NT
+		drivers do it in userspace.
+
+Code:		Please use the Linux style of code formatting as documented
+		in Documentation/CodingStyle. If you have sections of code
+		that need to be in other formats, for example because they
+		are shared with a windows driver kit and you want to
+		maintain them just once seperate them out nicely and note
+		this fact.
+
+Portability:	Pointers are not always 32bits, people do not all have
+		floating point and you shouldn't use inline x86 assembler in 
+		your driver without careful thought. Pure x86 drivers
+		generally are not popular. If you only have x86 hardware it 
+		is hard to test portability but it is easy to make sure the
+		code can easily be made portable.
+
+Clarity:	It helps if anyone can see how to fix the driver. It helps
+		you because you get patches not bug reports. If you submit a
+		driver that intentionally obfuscates how the hardware works
+		it will go in the bitbucket.
+
+Control:	In general if there is active maintainance of a driver by
+		the author then patches will be redirected to them unless 
+		they are totally obvious and without need of checking.
+		If you want to be the contact and update point for the
+		driver it is a good idea to state this in the comments.
+
+What Criteria Do Not Determine Acceptance
+-----------------------------------------
+
+Vendor:		Being the hardware vendor and maintaining the driver is
+		often a good thing. If there is a stable working driver from
+		other people already in the tree don't expect 'we are the
+		vendor' to get your driver chosen. Ideally work with the 
+		existing driver author to build a single perfect driver.
+
+Author:		It doesn't matter if a large Linux company wrote the driver,
+		or you did. Nobody has any special access to the kernel
+		tree. Anyone who tells you otherwise isn't telling the
+		whole story.
+
+
+Resources
+---------
+
+Linux kernel master tree:
+	ftp.kernel.org:/pub/linux/kernel/...
+
+Linux kernel mailing list:		
+	linux-kernel@vger.kernel.org
+	[mail majordomo@vger.kernel.org to subscribe]
+
+Kernel traffic:
+	Weekly summary of kernel list activity (much easier to read)
+	[http://kt.linuxcare.com/kernel-traffic]
+
+Linux USB project:
+	http://sourceforge.net/projects/linux-usb/
+