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
