How to run this (was Re: Linux Driver Project Status Report as of June 2009)
Greg KH
greg at kroah.com
Thu Jun 4 21:55:06 UTC 2009
On Thu, Jun 04, 2009 at 01:09:59PM -0700, Greg KH wrote:
> Goal one (write drivers) has been very successful. Myself and many
> other members of the LDP have written new drivers for a wide range of
> different hardware devices, and gotten them merged into the main kernel
> tree. Several more are currently under development and we are averaging
> about 2 querys a month for different drivers from different companies.
>
> This work will continue to happen in the following year, as everyone
> involved seems to be happy with it. However, there will be a few
> procedural changes in how this is working, to help resolve some of the
> issues that have occurred. For more details about this, see the
> discussion on the LDP development mailing list.
So, let's talk about the process of working on new drivers here. It's
been probably over a year since I last posted requests for developers to
the public list, and that I firmly my fault. I have been fufilling
developer requests usually by just contacting people on the list who I
know have experience in specific domains, or by doing the work myself.
This isn't very fair to the larger developer base here, and I apologize.
How do we fix this? I'll now promise to push developer requests to the
list in a much more timely fashion, and I have a few already that I will
send out after this thread.
But note, the majority of requests that I've been getting over the past
year has been "add this driver that we wrote out-of-tree" into the
kernel. That has happened through the creation of the staging tree, and
given that we have over 40 different drivers in that tree right now, has
been a very big success. Those kinds of requests I can handle myself,
as they are just merge issue. But when they happen, I will CC: this
developer list with the patches, so that people can jump on them if they
wish to.
That leads me to what I think is a good workflow for all different
levels of developers. I think we can handle all different levels of
experience of Linux kernel development:
Easy Tasks:
Look in the drivers/staging/*/TODO files and start sending me
patches implementing what is listed as needing to be done.
All drivers in those directories should have TODO files, and if they
don't, well, that's a patch someone can send me today :)
This development effort has been happening already, but a number of
different people, but given the growth of the staging tree, it can
easily handle a much larger effort.
Moderate Tasks:
Take a driver listed on the "out of tree drivers" list at:
http://www.linuxdriverproject.org/twiki/bin/view/Main/OutOfTreeDrivers
bundle it up in patch form under the drivers/staging/ directory, and
send it to me. Make sure you give the proper attribution to the
original developers, and then you can do the needed cleanup and
porting to the newer kernel apis that are usually needed to get it
working.
As an example of this, I have had a few people request the PPSCSI
drivers at:
http://penguin-breeder.org/kernel/download/
to be forward ported and merged into the tree. I tried to do this for
a few hours, but ran into struct sg issues that I couldn't easily
figure out. Someone familiar with block layer stuff can probably
handle this quite simply.
Advanced Tasks:
Write a new driver from scratch, or modify an existing driver for new
hardware.
This is the bigger requests that I get every so often. Sometimes it
comes with hardware, but sometimes without, but with specs.
I'll be posting a few of these requests to the list after this, but
they will take a larger effort, and ideally, the author would become
the maintainer for the driver after it is merged into the main kernel
tree.
Usually drivers written this way can skip the staging tree, and go
directly into the kernel, as they are written in the "proper" kernel
way.
So, sound reasonable? Any objections/questions?
Oh, where does this leave the prjmgr list? I really don't know, anyone
have any ideas?
thanks,
greg k-h
More information about the devel
mailing list