How to run this (was Re: Linux Driver Project Status Report as of June 2009)

Mithlesh Thukral mithlesh at linsyssoft.com
Fri Jun 5 10:00:50 UTC 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.
Hi Greg,

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:
>   	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.
>
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:
>   	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 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.

Regards,
Mithlesh Thukral
>
>   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?
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.

Regards,
Mithlesh Thukral

>
> thanks,
>
> greg k-h
> _______________________________________________
> devel mailing list
> devel at linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/devel




More information about the devel mailing list