English
- 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://wwww.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/
