Hello! I have several questions regarding how device drivers are merged into linux-kernel. First of all, I have found some document regarding submitting drivers to LK, but it looks like pretty out-dated, https://kernelnewbies.org/UpstreamMerge/SubmittingDrivers is this info still relevant? Or there is a new one? Actually, I want to know more about the process. To start with this, I would like to ask an example question. Surfing through the kernel source I have found several ra-link usb wi-fi adapter drivers (rtl8188eu, rtl8192e, rtl8712 ...). Suppose one have datasheet that gives the possibility for writing a device driver for say rtlxxxxx based device. Can third-party person write & submit this driver to LK or this must be done explicitly by device vendor? What are the requirements from LK community side? Are there any license issues with this? (besides the author should publish code under GPL)
On Mon, Mar 13, 2017 at 11:21:24PM +0300, alexhoppus wrote:
Hello!
I have several questions regarding how device drivers are merged into linux-kernel. First of all, I have found some document regarding submitting drivers to LK, but it looks like pretty out-dated, https://kernelnewbies.org/UpstreamMerge/SubmittingDrivers is this info still relevant? Or there is a new one?
Look in the kernel source tree at Documentation/SubmittingDrivers for the latest version.
Actually, I want to know more about the process. To start with this, I would like to ask an example question. Surfing through the kernel source I have found several ra-link usb wi-fi adapter drivers (rtl8188eu, rtl8192e, rtl8712 ...). Suppose one have datasheet that gives the possibility for writing a device driver for say rtlxxxxx based device. Can third-party person write & submit this driver to LK or this must be done explicitly by device vendor?
Anyone can submit a driver.
What are the requirements from LK community side?
It has to match our coding style rules and pass our code review.
Are there any license issues with this? (besides the author should publish code under GPL)
Nope, just has to be compatible with GPLv2. Do you have a specific driver you wish to get merged that isn't already in the tree? thanks, greg k-h
On 14.03.2017 00:45, Greg KH wrote:
On Mon, Mar 13, 2017 at 11:21:24PM +0300, alexhoppus wrote:
Hello!
I have several questions regarding how device drivers are merged into linux-kernel. First of all, I have found some document regarding submitting drivers to LK, but it looks like pretty out-dated, https://kernelnewbies.org/UpstreamMerge/SubmittingDrivers is this info still relevant? Or there is a new one?
Look in the kernel source tree at Documentation/SubmittingDrivers for the latest version.
Actually, I want to know more about the process. To start with this, I would like to ask an example question. Surfing through the kernel source I have found several ra-link usb wi-fi adapter drivers (rtl8188eu, rtl8192e, rtl8712 ...). Suppose one have datasheet that gives the possibility for writing a device driver for say rtlxxxxx based device. Can third-party person write & submit this driver to LK or this must be done explicitly by device vendor?
Anyone can submit a driver.
What are the requirements from LK community side?
It has to match our coding style rules and pass our code review.
Are there any license issues with this? (besides the author should publish code under GPL)
Nope, just has to be compatible with GPLv2.
Do you have a specific driver you wish to get merged that isn't already in the tree?
No, I just try to understand the process. I don't fully understand what is the role of independent developer in the process of submitting new drivers to LK. What I mean is - hardware device vendors always ship device driver with their products. In this case several options are available: 1.) HW vendor ships only closed-source drivers and is not interested to open source this work. 2.) HW vendor publishes device drivers to the community by himself 3.) HW vendor put the device driver sources to their website ready for downloading and building, but make no effort for integrating them to LK. Actually, I see that in this plot independent developer could only participate in case 3 - i.e. take the published sources, fix coding style, satisfy other community needs and integrate this driver to LK (By the way is this a real case? Or drivers aren't integrated in such way?). I see no other ways how independent person could participate. Am I wrong?
thanks,
greg k-h
On Tue, 14 Mar 2017 22:54:37 +0300, alexhoppus said:
No, I just try to understand the process. I don't fully understand what is the role of independent developer in the process of submitting new drivers to LK. What I mean is - hardware device vendors always ship device driver with their products. In this case several options are available: 1.) HW vendor ships only closed-source drivers and is not interested to open source this work. 2.) HW vendor publishes device drivers to the community by himself 3.) HW vendor put the device driver sources to their website ready for downloading and building, but make no effort for integrating them to LK.
You missed one: 4.) HW vendor only ships a Windows or OSX client. This happens more often than you think. At which point, somebody buys the widget and reverse-engineers it. This is trivial if the device chipset is already supported - it may just be a matter of adding the devices PCI or USB ID to the driver code's table. If it's similar to an existing device that's supported, the data sheet and some hacking may be required. And sometimes, you're stuck with using a JTAG and a logic analyzer.
Actually, I see that in this plot independent developer could only participate in case 3 - i.e. take the published sources, fix coding style, satisfy other community needs and integrate this driver to LK (By the way is this a real case? Or drivers aren't integrated in such way?). I see no other ways how independent person could participate. Am I wrong?
Or the developer could take an existing in-tree driver and patch it to work. This has also been done plenty of times (especially for vendors who have released long series of hardware that's fairly similar). Or the developer could just write the entire driver. This has been done plenty of times. Alan Cox probably holds the record for most drivers written. :)
valdis.kletnieks@vt.edu writes:
On Tue, 14 Mar 2017 22:54:37 +0300, alexhoppus said:
No, I just try to understand the process. I don't fully understand what is the role of independent developer in the process of submitting new drivers to LK. What I mean is - hardware device vendors always ship device driver with their products. In this case several options are available: 1.) HW vendor ships only closed-source drivers and is not interested to open source this work. 2.) HW vendor publishes device drivers to the community by himself 3.) HW vendor put the device driver sources to their website ready for downloading and building, but make no effort for integrating them to LK.
You missed one:
4.) HW vendor only ships a Windows or OSX client.
And another one: 5.) vendor independent class drivers IMHO perfect for the independent developer since there will be documentation available. The USB class specs are freely available for example. Bjørn
On Tue, 14 Mar 2017 21:59:20 +0100, Bjørn Mork said:
And another one:
5.) vendor independent class drivers
IMHO perfect for the independent developer since there will be documentation available. The USB class specs are freely available for example.
Hmm... /sys/class has a bunch of stuff already. How many class drivers are missing from there? And more importantly, class drivers for a hardware class that's actually available (i.e. neither extinct or not shipping yet)?
On Tue, Mar 14, 2017 at 05:14:12PM -0400, valdis.kletnieks@vt.edu wrote:
On Tue, 14 Mar 2017 21:59:20 +0100, Bjørn Mork said:
And another one:
5.) vendor independent class drivers
IMHO perfect for the independent developer since there will be documentation available. The USB class specs are freely available for example.
Hmm... /sys/class has a bunch of stuff already.
/sys/class has nothing to do with a USB class specification :)
How many class drivers are missing from there? And more importantly, class drivers for a hardware class that's actually available (i.e. neither extinct or not shipping yet)?
A USB "class" is a set of devices that follow a published specification. Like a USB HID device (keyboard/mouse/etc.) These are all published on the usb.org website. I think there still are a few class specs that are not yet implemented on Linux, usually because no one actually made any devices for them, or not enough that anyone really cares. A /sys/class/ entry is a kernel subsystem that describes a set of devices that interact with userspace in a defined way. Like an "input" class. That is how userspace interacts with _all_ keyboards, be they USB or PS/2 or i2c or whatever. Hope this helps, greg k-h
participants (4)
-
alexhoppus -
Bjørn Mork -
Greg KH -
valdis.kletnieks＠vt.edu