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