|
This is a status report for the Linux Driver Project as of April 2008, describing what has happened in the past year of work. It was originally posted on the developer mailing list. Executive SummaryThe Linux Driver Project (LDP) is alive and well, with over 300 developers wanting to participate, many drivers already written and accepted into the Linux kernel tree, and many more being currently developed. The main problem is a lack of projects. It turns out that there really isn't much hardware that Linux doesn't already support. Almost all new hardware produced is coming with a Linux driver already written by the company, or by the community with help from the company. There are two main classes of hardware, video input devices and wireless network cards, that is not well supported by Linux, but large efforts are already underway to resolve this issue, with the wireless driver issue pretty much taken care of already, however there are a few notable exceptions. Because of this, our main effort has turned into one of education. Educating vendors of how to become members of the Linux kernel community, proper coding standards and procedures, and how to get their code into the kernel tree. Much of our recent effort has been in code cleanup and shepherding into the kernel.org releases. In the future, we are open to any new devices that need drivers to be written for them, and our procedure for handling projects is going to be changing to reflect the lessons learned in the past year to make things easier for vendors to participate, and for the community to easily detect what is going on and be able to help out in easier ways. The Past YearThe BeginningThe Linux Driver Project (LDP) was born a little over a year ago with an announcement on the linux-kernel mailing list and a few blog postings. It sprang up out of the complaints from some users and companies that there was a real "Linux driver problem". The perception was that Linux did not have good driver support, and that closed source drivers were potentially taking over some device types. I figured that if we reduced the barrier for any company to have a Linux driver written for them to nothing except a few emails, a document or two, and hopefully a sample device, these problems would go away and we would be able to create a raft of opensource drivers for these problem devices that everyone seemed to be complaining about. So the LDP was born. It started out as a single place for hardware manufacturers to contact in order to get drivers written for their devices for free. We allowed the ability for companies to sign an NDA if needed to help get over the hurdle that some companies have in releasing their specifications. The NDA process was put into place through the Linux Foundation, and is a 3-way NDA with all of the proper legal documents needed. A funny thing happened though, what I figured would be a project flooded with requests for companies to get hardware working turned into anything but that. Two major things then happened, both of which I could have never expected:
It's this last point that made me worry. Yes, a number of companies did ask for drivers to be written, and we have done so, but not as many as I originally imagined. The drivers we were writing were in the narrow vertical markets, all interesting devices and companies, but nothing really "mainstream". So where was this mass of hardware that Linux wasn't supporting? The Linux Driver MythBack in 2006 I gave a talk at the Ottawa Linux Symposium about a number of myths that are around the Linux kernel. One of them was device and driver support. I stated then, and still do that:
Later on, a representative from Microsoft validated this statement saying that their research agreed with it, so this is not an unproven statement. Yet still the "Linux has a driver problem" myth persisted. The OSDL and then later the Linux Foundation's Vendor Advisory board had "Linux drivers" as the second most pressing issue that they faced. Surely these large vendors, all of which shipped Linux on their hardware and dealt with user issues every day were on to something. So the LDP was created. And no companies showed up. So I spread the word some more. And still no major companies showed up. So what to do. I tried my best with a general announcement of, "Tell me all of the hardware that you know of that is not supported by Linux!" The response by users was overwhelming. My inbox was flooded with hundreds of messages, and the wiki page: http://www.linuxdriverproject.org/twiki/bin/view/Main/DriversNeeded was created. This is the community's best list of devices that are not currently supported on Linux as of today. I then went and asked all of the individual companies that made up the Linux Foundation's Vendor Advisory board what they needed for Linux drivers. The conversation almost always went like this: "What hardware do you ship that is not currently supported by Linux?" VENDOR ME VENDOR After much cajoling and harassment on my part, I'm happy to say that the Linux Foundation's Vendor Advisory board's top 10 list of things that need to be worked on with Linux doesn't mention drivers at all. So let's put this myth to rest once and for all please. User ComplaintsBut wait, what about all of those email responses that I received. It turns out that they can be categorized into four different groups: 1) Printer and Scanner support. 2) Older devices no longer manufactured that people really want to see working on their Linux machines someday. 3) Wireless device support 4) Video input device support. Category 1 is already being handled very well by the Linux Printing project and the SANE project. Printer and scanner drivers in Linux are userspace programs and libraries and have nothing to do with the kernel at all. If you have any issues with these types of devices, please go ask the developers of those projects about it. They are very knowledgeable, skilled, have vendor contacts, and can do a lot to help resolve your issues. This area is already aptly covered by these people. Category 2 is hard. It would be great for Linux to support all of these older devices, but without the specs for the device, or in many cases, a company that is still in business, Linux support is going to be very difficult to achieve. Reverse engineering is a great skill, one that I personally am no good at anymore. This type of effort is not something that the LDP was set up to address, and luckily, for almost all modern hardware devices, it is not necessary. So that leave wireless and video input devices. Luckily both classes of these devices have a very active and productive developer community surrounding them. The Linux-Wireless group of developers have done an amazing amount of work in the past year, adding a whole new wireless protocol stack to the Linux kernel, as well as numerous different hardware drivers, some initially created by vendors and others created by reverse engineering the hardware with no vendor help or approval. The latest kernel.org releases contain a raft of new hardware support for wireless drivers, and the number of active drivers in their queue to be added in the near future is quite large. There are still some wireless vendors that do not provide Linux support directly. Two of these, Atheros and Broadcom have drivers created by the community through reverse engineering efforts. These drivers usually lag the introduction of the hardware by a number of months due to the lack of vendor support. Both of these companies have internal versions of drivers for their new hardware, but efforts on getting them to release them so far has been resisted. Hopefully this will change in the future. As for video input devices, there is an active Linux developer community in this area, but they seem to be hampered by a different development model (Mecurial trees outside of the main kernel source), and a lack of full-time developers, not to mention a high degree of inter-personal conflicts that seem quite strange to outsiders. Support for a large majority of these devices is slowly trickling into the main kernel tree, the most important being the USB Video class driver, which will support almost all new USB video devices in the future, thereby removing the major problem most users will face when purchasing a new video device. The LDP group is also actively working on drivers for a number of different video devices today, with the code being available today for testing by users in the linux-next kernel releases. These drivers should go into a kernel.org release in the near future when development is complete. EducationDuring the past year, I have had many different inquiries from different companies wishing to either have a driver written for their hardware, or to help get an existing driver into the Linux kernel source tree. Almost all of these contacts has resulted in a process of helping to educate the vendor as to how the kernel community works, if a driver is even needed for their hardware (in many cases it was not), and how to clean up their code for acceptance. Despite my personal feeling that Linux has a very well documented procedure of how kernel development works, along with free books explaining how to do kernel development, it seems we still have a lot of work to go. We need some way to help spread the message further to companies that are just starting out with Linux development. Maybe we need to sign up a marketing department from some major Linux vendor to help out with this kind of effort. In the past year I have given talks at many different companies all around the world on how the Linux kernel development process works, and I see this travel and speaking effort not ending any time soon. I have started to recruit more developers to help out with this education process, but can always use more help. If anyone wants to participate, and is comfortable in explaining our kernel development procedures, please let me know. It is this kind of education that has helped out the most so far. Lots of drivers have been cleaned up through the education process and eventually accepted into the kernel tree. This effort will continue on, and has already started to move a lot of out-of-tree drivers into the main kernel.org tree Method of DevelopmentWhen the LDP project was started, the structure of having a project manager for the individual project, and a number of developers working on each one was established. Over the past year, this has worked for some projects, while for others, it has failed badly. Some project teams have disappeared, including both project managers and developers. This is quite common for opensource projects, so we need a way to route around the problem of this, allowing everyone to participate in a more open model. To try to work toward this, I've started to keep all code related to the LDP project in a quilt patch series. It can be seen at: and is now automatically included in the linux-next daily kernel releases. This quilt series is contained within a git tree at that can be accessed at: This tree provides a place where developers can provide changes, updates, and see where they can help out if they wish to do so in a much easier manner. It also provides a way for companies participating to observe the status of their code in a much more open manner. The FutureSo, what next? I have the following goals for the LDP in the next year:
ThanksI'd first like to thank my employer, Novell, for giving me the opportunity to work on this project full time. Their acceptance and support for the LDP is amazing and has been what has allowed it to survive and produce such great results already in a short amount of time. I'd also like to thank all of the developers who have offered to help out with this project. Your volunteering to participate is amazing and shows the strength of the Linux developer community. I'd also like to thank Tomasz Grzegurzko for maintaining and keeping the linuxdriverproject.org domain and server up and running so well, despite my best attempts to do stupid things with it at times. Also thanks to the OSU Open Source Labs for your domain and bandwidth support of the project. posted Mon, 07 Apr 2008 in [/linux] |
|
My Linux Stuff RSS |
|
||