When to submit into drivers/staging

When to submit into drivers/staging

[Johannes Thumshirn]

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.

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.

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

Thanks a lot,

       Johannes

When to submit into drivers/staging

[Bjørn Mork]

Johannes Thumshirn <johannes.thumshirn@men.de> 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

When to submit into drivers/staging

[Johannes Thumshirn]

On Mon, Feb 10, 2014 at 09:45:20AM +0100, Bj?rn Mork wrote:
> Johannes Thumshirn <johannes.thumshirn@men.de> 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