Hi all,
It's been about a year since the linux driver project was started, so I
figured that it was about time for a status report of how things are
going, and how things are going to be changing a bit for the future.
Thanks again for everyone that has participated so far, I, and all of
the Linux users out there, really appreciate it.
greg k-h
------------
Linux Driver Project Status Report as of April 2008
Executive Summary
The 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 Year
The Beginning
The 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:
- The number of developers who said they would be willing to help out
in creating these drivers was amazing. As of today, we have over
300 different people who have signed up to be a developer of a Linux
driver, volunteering their talents and time to help Linux out. This
large developer base is a shining example of how strong and large
the Linux community is.
- Very few companies signed up for drivers.
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 Myth
Back 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:
Linux supports more different types of devices than any other
operating system ever has in the history of computing.
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:
ME
"What hardware do you ship that is not currently supported by Linux?"
VENDOR
"It all is."
ME
"But wait, why are you claiming that 'Linux drivers' is your second
most pressing issue today with Linux?"
VENDOR
"I don't know."
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 Complaints
But 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.
Education
During 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 Development
When 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:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/ldp/
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:
http://git.kernel.org/?p=linux/kernel/git/gregkh/patches.git
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 Future
So, what next? I have the following goals for the LDP in the next year:
- Continue to write new drivers for any company that wishes to have
them developed. These drivers are all to be released under the
GPLv2 and included in the main Linux kernel source tree hosted at
kernel.org. Future maintenance of these drivers will be done either
by members of the original company, or by the community members,
depending on the wishes of the company.
- Continue to be a focal point for companies to learn about the Linux
development process and become part of the kernel community if they
wish to. I hope to enlist more people to help out with this
process, but if not, my airline miles logged will continue to
increase.
- Work more in an open development manner, hosting all experimental
and development code in a public git tree, getting daily testing in
the linux-next tree on all architectures.
Thanks
I'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.
