How to run this (was Re: Linux Driver Project Status Report as of June 2009)
mithlesh at linsyssoft.com
Fri Jun 5 03:00:50 PDT 2009
On Friday 05 June 2009 03:25:06 Greg KH wrote:
> 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.
First of all its really great you thought of this idea and kept it going for
so long. And its amazing to see so many people involved.
> 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.
I am already doing this. Its sort of a way to help the effort as these days
my work is keeping me real busy and dont need to spend a lot of time on these
TODO item. But atleast the good work keeps on :)
> 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
Sure I will mark this as a personal TODO item.
> 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.
I have a good experience developing Linux network device drivers and have
tried my hand in some other devices also. So I would be more than pleased to
contribute to the same.
> 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?
> Oh, where does this leave the prjmgr list? I really don't know, anyone
> have any ideas?
bit off topic suggestion, can we have mailing list for staging tree. This
comes out of a personally experienced situation where in I was working a
particular large patchset and someone already had sent a patch to Greg. That
patch ended in staging tree almost minutes before I could send out the first
mail. So my entire patchset had to be reworked.
Mailing list doesnt eliminate collision window, but drastically reduces it.
> greg k-h
> devel mailing list
> devel at linuxdriverproject.org
More information about the devel