|author||Linus Torvalds <email@example.com>||2005-04-16 15:20:36 -0700|
|committer||Linus Torvalds <firstname.lastname@example.org>||2005-04-16 15:20:36 -0700|
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
Diffstat (limited to 'Documentation/SubmittingDrivers')
1 files changed, 145 insertions, 0 deletions
diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers
new file mode 100644
@@ -0,0 +1,145 @@
+Submitting Drivers For The Linux Kernel
+This document is intended to explain how to submit device drivers to the
+various kernel trees. Note that if you are interested in video card drivers
+you should probably talk to XFree86 (http://www.xfree86.org/) and/or X.Org
+Also read the Documentation/SubmittingPatches document.
+Allocating Device Numbers
+Major and minor numbers for block and character 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
+ No new drivers are accepted for this kernel tree
+ 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 <email@example.com>
+ The same rules apply as 2.2. The final contact point for Linux 2.4
+ submissions is Marcelo Tosatti <firstname.lastname@example.org>.
+ The same rules apply as 2.4 except that you should follow linux-kernel
+ to track changes in API's. The final contact point for Linux 2.6
+ submissions is Andrew Morton <email@example.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.
+Copyright: The copyright owner must agree to use of GPL.
+ It's best if the submitter and copyright owner
+ are the same person/entity. If not, the name of
+ the person/entity authorizing use of GPL should be
+ listed in case it's necessary to verify the will of
+ the copright owner.
+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 separate them out nicely and note
+ this fact.
+Portability: Pointers are not always 32bits, not all computers are little
+ endian, 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
+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,
+ and include an entry in MAINTAINERS for your driver.
+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.
+Linux kernel master tree:
+ ?? == your country code, such as "us", "uk", "fr", etc.
+Linux kernel mailing list:
+ [mail firstname.lastname@example.org to subscribe]
+Linux Device Drivers, Third Edition (covers 2.6.10):
+ http://lwn.net/Kernel/LDD3/ (free version)
+ Weekly summary of kernel list activity (much easier to read)
+ Weekly summary of kernel development activity - http://lwn.net/
+ 2.6 API changes:
+ Porting drivers from prior kernels to 2.6:
+ Occasional Linux kernel articles and developer interviews
+ Documentation and assistance for new kernel programmers
+Linux USB project: