Getting started with new driver

Getting started with new driver

[Chris Caudle]

I am helping review a new network audio driver that is being developed as
an ALSA virtual sound card.
The developer is experienced in programming, but not much in interacting
with open source development.
I am out of practice in programming, but would like to help with community
interaction, so need some advice on getting started submitting a new
driver for review.

My first assumption is that since ALSA has been part of the kernel tree
for quite a while all the code should match the kernel style guide
(basically K&R style).  Is that correct?

There is some cleanup to do there, as well as some cleanup to match some
recent kernel API changes (e.g. is currently using tasklet timers, but I
think those are pulled out now so will need to switch to softirq timers).

Once I can help get the style and API usage cleaned up, how should a new
driver be submitted for review?  It is currently in a semi-private tree on
bitbucket.org. A series of patches as email?  One big email that contains
all of the driver source?  Some other way?  The alsa-project.org page
doesn't really have a "getting started on a new driver for newbies" page
that I could find.

thanks,
Chris Caudle

Re: Getting started with new driver

[Takashi Iwai]

On Sat, 09 Dec 2017 19:04:43 +0100,
Chris Caudle wrote:
> 
> I am helping review a new network audio driver that is being developed as
> an ALSA virtual sound card.
> The developer is experienced in programming, but not much in interacting
> with open source development.
> I am out of practice in programming, but would like to help with community
> interaction, so need some advice on getting started submitting a new
> driver for review.
> 
> My first assumption is that since ALSA has been part of the kernel tree
> for quite a while all the code should match the kernel style guide
> (basically K&R style).  Is that correct?

The detailed coding style is found in
Documentation/process/coding-style.rst.
In doubt, try to check via scripts/checkpatch.pl.

> There is some cleanup to do there, as well as some cleanup to match some
> recent kernel API changes (e.g. is currently using tasklet timers, but I
> think those are pulled out now so will need to switch to softirq timers).
> 
> Once I can help get the style and API usage cleaned up, how should a new
> driver be submitted for review?  It is currently in a semi-private tree on
> bitbucket.org. A series of patches as email?  One big email that contains
> all of the driver source?  Some other way?  The alsa-project.org page
> doesn't really have a "getting started on a new driver for newbies" page
> that I could find.

There is no difference from any other kernel stuff: just submit the
patch(es) to the corresponding subsystem mailing list.  In the case of
sound drivers, submit to alsa-devel ML, and don't forget to put Cc to
the maintainers.

The detailed procedure for a patch submission is found in
Documentation/process/submitting-patches.rst.  It's a bit lengthy, but
worth to read through.


thanks,

Takashi