Re: [Updated v3]: How to become a kernel driver maintainer

["Randy.Dunlap" <rdunlap@xenotime.net>]

On Fri, 02 Jun 2006 17:38:36 -0400 Ben Collins wrote:

> This got back-burnered for awhile, but here's the fixed up copy from the
> last round of feedback. Thanks to everyone that's given input. It's all
> been helpful and I think this copy reflects everything that was
> discussed last time.
> 
> If there's no major changes requested, the next time will be in diff
> format for Documentation/ inclusion.

Having the text inline for review/comments sure would be a lot
easier on reviewers.


| There are also many targets in the kernel build system (KBuild) that will
| help check your code as well. These targets are listed if you type "make
| help" in the kernel tree. Some targets of note are, checkstack,
| buildcheck and namespacecheck. You can also add C=1 to the make arguments,
| in order to use the sparse tool for checking your code.

'buildcheck' is gone.  It is done automatically at the end of
every build.

Grammar fixes:
Some targets of note are "checkstack" and "namespacecheck".
You can also add C=1 to the 'make' arguments
in order to use the sparse tool for checking your code.

|   - When creating the Kconfig entries

I would add something like:
Also do not enable (y or m) Kconfig options by default.
Users should enable them and we don't want to increase kernel size
for people who don't need this.

Spello:
and your users (and is often times seen as a rite of passage).
"oftentimes"
and later:
Often times, it is necessary
"Oftentimes,"

| This is where some maintainers fail, and is the reason the kernel
| developers are so reluctant to allow new drivers into the main tree.

I still disagree with that conclusion (as I also wrote on
8-Mar-2006).  I think that it's basically a matter of if the
(driver) submitter is willing to do the work as documented in
Documentation/* and listen to review feedback and act on that
or explain why changes shouldn't be made, then the code will
likely be accepted (if it's *correct*, of course).

| There are times where changes
should be
"times when" or "places where"


---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/