1 |
1275 |
phoenix |
Submitting Drivers For The Linux Kernel
|
2 |
|
|
---------------------------------------
|
3 |
|
|
|
4 |
|
|
This document is intended to explain how to submit device drivers to the
|
5 |
|
|
various kernel trees. Note that if you are interested in video card drivers
|
6 |
|
|
you should probably talk to XFree86 (http://www.xfree86.org) instead.
|
7 |
|
|
|
8 |
|
|
Also read the Documentation/SubmittingPatches document.
|
9 |
|
|
|
10 |
|
|
|
11 |
|
|
Allocating Device Numbers
|
12 |
|
|
-------------------------
|
13 |
|
|
|
14 |
|
|
Major and minor numbers for block and character devices are allocated
|
15 |
|
|
by the Linux assigned name and number authority (currently better
|
16 |
|
|
known as H Peter Anvin). The site is http://www.lanana.org/. This
|
17 |
|
|
also deals with allocating numbers for devices that are not going to
|
18 |
|
|
be submitted to the mainstream kernel.
|
19 |
|
|
|
20 |
|
|
If you don't use assigned numbers then when you device is submitted it will
|
21 |
|
|
get given an assigned number even if that is different from values you may
|
22 |
|
|
have shipped to customers before.
|
23 |
|
|
|
24 |
|
|
Who To Submit Drivers To
|
25 |
|
|
------------------------
|
26 |
|
|
|
27 |
|
|
Linux 2.0:
|
28 |
|
|
No new drivers are accepted for this kernel tree
|
29 |
|
|
|
30 |
|
|
Linux 2.2:
|
31 |
|
|
If the code area has a general maintainer then please submit it to
|
32 |
|
|
the maintainer listed in MAINTAINERS in the kernel file. If the
|
33 |
|
|
maintainer does not respond or you cannot find the appropriate
|
34 |
|
|
maintainer then please contact Alan Cox
|
35 |
|
|
|
36 |
|
|
Linux 2.4:
|
37 |
|
|
The same rules apply as 2.2. The final contact point for Linux 2.4
|
38 |
|
|
submissions is Marcelo Tosatti .
|
39 |
|
|
|
40 |
|
|
Linux 2.5:
|
41 |
|
|
The same rules apply as 2.4 except that you should follow linux-kernel
|
42 |
|
|
to track changes in API's. The final contact point for Linux 2.5
|
43 |
|
|
submissions is Linus Torvalds .
|
44 |
|
|
|
45 |
|
|
What Criteria Determine Acceptance
|
46 |
|
|
----------------------------------
|
47 |
|
|
|
48 |
|
|
Licensing: The code must be released to us under the
|
49 |
|
|
GNU General Public License. We don't insist on any kind
|
50 |
|
|
of exclusively GPL licensing, and if you wish the driver
|
51 |
|
|
to be useful to other communities such as BSD you may well
|
52 |
|
|
wish to release under multiple licenses.
|
53 |
|
|
|
54 |
|
|
Interfaces: If your driver uses existing interfaces and behaves like
|
55 |
|
|
other drivers in the same class it will be much more likely
|
56 |
|
|
to be accepted than if it invents gratuitous new ones.
|
57 |
|
|
If you need to implement a common API over Linux and NT
|
58 |
|
|
drivers do it in userspace.
|
59 |
|
|
|
60 |
|
|
Code: Please use the Linux style of code formatting as documented
|
61 |
|
|
in Documentation/CodingStyle. If you have sections of code
|
62 |
|
|
that need to be in other formats, for example because they
|
63 |
|
|
are shared with a windows driver kit and you want to
|
64 |
|
|
maintain them just once seperate them out nicely and note
|
65 |
|
|
this fact.
|
66 |
|
|
|
67 |
|
|
Portability: Pointers are not always 32bits, not all computers are little
|
68 |
|
|
endian, people do not all have floating point and you
|
69 |
|
|
shouldn't use inline x86 assembler in your driver without
|
70 |
|
|
careful thought. Pure x86 drivers generally are not popular.
|
71 |
|
|
If you only have x86 hardware it is hard to test portability
|
72 |
|
|
but it is easy to make sure the code can easily be made
|
73 |
|
|
portable.
|
74 |
|
|
|
75 |
|
|
Clarity: It helps if anyone can see how to fix the driver. It helps
|
76 |
|
|
you because you get patches not bug reports. If you submit a
|
77 |
|
|
driver that intentionally obfuscates how the hardware works
|
78 |
|
|
it will go in the bitbucket.
|
79 |
|
|
|
80 |
|
|
Control: In general if there is active maintainance of a driver by
|
81 |
|
|
the author then patches will be redirected to them unless
|
82 |
|
|
they are totally obvious and without need of checking.
|
83 |
|
|
If you want to be the contact and update point for the
|
84 |
|
|
driver it is a good idea to state this in the comments,
|
85 |
|
|
and include an entry in MAINTAINERS for your driver.
|
86 |
|
|
|
87 |
|
|
What Criteria Do Not Determine Acceptance
|
88 |
|
|
-----------------------------------------
|
89 |
|
|
|
90 |
|
|
Vendor: Being the hardware vendor and maintaining the driver is
|
91 |
|
|
often a good thing. If there is a stable working driver from
|
92 |
|
|
other people already in the tree don't expect 'we are the
|
93 |
|
|
vendor' to get your driver chosen. Ideally work with the
|
94 |
|
|
existing driver author to build a single perfect driver.
|
95 |
|
|
|
96 |
|
|
Author: It doesn't matter if a large Linux company wrote the driver,
|
97 |
|
|
or you did. Nobody has any special access to the kernel
|
98 |
|
|
tree. Anyone who tells you otherwise isn't telling the
|
99 |
|
|
whole story.
|
100 |
|
|
|
101 |
|
|
|
102 |
|
|
Resources
|
103 |
|
|
---------
|
104 |
|
|
|
105 |
|
|
Linux kernel master tree:
|
106 |
|
|
ftp.??.kernel.org:/pub/linux/kernel/...
|
107 |
|
|
?? == your country code, such as "us", "uk", "fr", etc.
|
108 |
|
|
|
109 |
|
|
Linux kernel mailing list:
|
110 |
|
|
linux-kernel@vger.kernel.org
|
111 |
|
|
[mail majordomo@vger.kernel.org to subscribe]
|
112 |
|
|
|
113 |
|
|
Kernel traffic:
|
114 |
|
|
Weekly summary of kernel list activity (much easier to read)
|
115 |
|
|
[http://kt.zork.net/kernel-traffic]
|
116 |
|
|
|
117 |
|
|
Linux USB project:
|
118 |
|
|
http://sourceforge.net/projects/linux-usb/
|
119 |
|
|
|