Messages in this thread |  | | | Date | Fri, 2 Jun 2006 15:16:39 -0700 | | From | "Randy.Dunlap" <> | | Subject | Re: [Updated v3]: How to become a kernel driver maintainer |
| |
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/
|  |