How to run this (was Re: Linux Driver Project Status Report as of June 2009)
felipebalbi at users.sourceforge.net
Thu Jun 4 23:00:02 PDT 2009
First of all congratulations for the great results of LDP so far.
On Fri, Jun 5, 2009 at 12:55 AM, Greg KH<greg at kroah.com> wrote:
> 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.
Yeah, that's nice. More people would have the possibility to work and/or learn
> 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.
sounds good to me and very 'linux friendly'. If the driver is there and is
gpl, anyone can work on it.
> 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:
> 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
> As an example of this, I have had a few people request the PPSCSI
> drivers at:
> 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
> This is the bigger requests that I get every so often. Sometimes it
> comes with hardware, but sometimes without, but with specs.
If it comes with specs, then it should be ok. Although parts of it should
be tricky to get working, we at least would have access to documentation
on the hw.
> 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
> Usually drivers written this way can skip the staging tree, and go
> directly into the kernel, as they are written in the "proper" kernel
> So, sound reasonable? Any objections/questions?
I second that, all sounds really good. And looks like the drivers will
be cleaned sooner than later (for the staging drivers)
More information about the devel