| Submitting Drivers For The Linux Kernel |
| --------------------------------------- |
| |
| This document is intended to explain how to submit device drivers to the |
| Linux 2.2 and 2.4 kernel trees. Note that if you are interested in video |
| card drivers you should probably talk to XFree86 (http://www.xfree86.org) |
| instead. |
| |
| 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 |
| ------------------------ |
| |
| 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.4: |
| 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, |
| 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. |
| |
| |
| Resources |
| --------- |
| |
| Linux kernel master tree: |
| ftp.??.kernel.org:/pub/linux/kernel/... |
| ?? == your country code, such as "us", "uk", "fr", etc. |
| |
| 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.zork.net/kernel-traffic] |
| |
| Linux USB project: |
| http://sourceforge.net/projects/linux-usb/ |
| |