On Mon, Feb 10, 2014 at 09:45:20AM +0100, Bjørn Mork wrote: > Johannes Thumshirn <johannes.thumshirn@xxxxxx> writes: > > > Hi, > > > > I have a question regarding driver submission into mainline. I'm not exactly > > sure if my driver is ready to be submittet into normal drivers or if it would be > > better to submit it to staging first. > > New drivers do not normally go through staging. If your driver is > mostly following the kernel coding standards and using appropriate > kernel interfaces, then, in my opinion, there is no reason to submit it > to staging first. I'd submit as a normal driver first, and then only > consider staging if the initial feedback indicates that major changes > are necessary before the driver is ready for mainline. > > My impression is that staging is primarily for code which was written > without Linux mainline in mind. > > > Is there any recomendation when to submit to drivers/staging instead of drivers? > > I've searched the archives but haven't found an answer to it. If you can instead > > just point me to a document I'm fine. > > I believe Documentation/development-process/2.Process gives the best > description of what staging is for: > > <quote> > 2.4.1: STAGING TREES > > The kernel source tree contains the drivers/staging/ directory, where > many sub-directories for drivers or filesystems that are on their way to > being added to the kernel tree live. They remain in drivers/staging while > they still need more work; once complete, they can be moved into the > kernel proper. This is a way to keep track of drivers that aren't > up to Linux kernel coding or quality standards, but people may want to use > them and track development. > > Greg Kroah-Hartman currently maintains the staging tree. Drivers that > still need work are sent to him, with each driver having its own > subdirectory in drivers/staging/. Along with the driver source files, a > TODO file should be present in the directory as well. The TODO file lists > the pending work that the driver needs for acceptance into the kernel > proper, as well as a list of people that should be Cc'd for any patches to > the driver. Current rules require that drivers contributed to staging > must, at a minimum, compile properly. > > Staging can be a relatively easy way to get new drivers into the mainline > where, with luck, they will come to the attention of other developers and > improve quickly. Entry into staging is not the end of the story, though; > code in staging which is not seeing regular progress will eventually be > removed. Distributors also tend to be relatively reluctant to enable > staging drivers. So staging is, at best, a stop on the way toward becoming > a proper mainline driver. > </quote> > > > The driver(s) in question is a bus driver for multi function FPGAs made by my > > company and one first iio/adc driver using this bus. It was sucessfully tested > > on x86 but is known to crash on powerpc because of my parser code (which will of > > cause be fixed when submitting, even into staging). > > If it is a new class of driver then I guess that means that you will > define some new APIs. Which is all the more reason to get it directly > into mainline. You cannot extend or define any kernel interfaces from > staging. > > > Bjørn Thanks for the answer Bjørn. I wrote the driver to be submittable into mainline and defined a new API, so I'll send directly to lkml when it has a good stable point (hopefully the next 1-2 Weeks). Thanks Johannes _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
