Differences between revisions 10 and 11
|Deletions are marked like this.||Additions are marked like this.|
|Line 16:||Line 16:|
|* [https://www.kernel.org/doc/Documentation/SubmittingDrivers Documentation/SubmittingDrivers]||* [https://www.kernel.org/doc/Documentation/process/submitting-drivers.rst Documentation/SubmittingDrivers]|
Why did you write this?
A lot of this stuff isn't written down, even in CodingStyle.
Why should you do all of this?
Remember, the public Linux community has a much different culture than just about any company. Posting a patch to LKML is a lot like going to a foreign land: things that are everyday practices for you might be a major faux pas for them.
Use a mailer which has a reputation for doing the right thing with plain-text attachments (which patches are). This means that you may want to consider using a mailer other than the one your company provides (Microsoft Outlook, Lotus Notes, etc...), at least to send or discuss patches. Mailers like pine, mutt, thunderbird, and even Evolution are known to be quite functional in this regard.
HTML mail is not permitted on the Linux Kernel Mailing List (and many others). This is partly due to the fact that many developers read their mail in console-based mail clients. On many lists, any mail containing HTML may be silently and automatically dropped by mailing list management software. Please verify that your mail is sent only as plain-text. You can often do this by sending a mail to yourself, viewing its source, and looking for any HTML sections.
Release early, release often
The more you work on something, the more invested in it you get. Remember that a random community member will not have the same level of commitment to your code. Try to enlighten them and confer to them why this feature is important and why you need it.
Don't work in isolation. Code developed in a vacuum can deviate significantly enough from what is acceptable in Linux that it will never get accepted. Receiving constant feedback from other people who work on Linux should keep this from ever happening.
While releasing often, try to have multiple levels of review
Solve generic problems
Making a controversial change to generic code, and cementing it to your driver/patch can have disastrous results. There are many ways to approach a given problem, and it should be obvious that you're willing to try several methods to get what you want. (this doesn't really apply to things like Makefiles or Kconfig)
Sometimes, when I'm about to make a horrible hack in my code, I take a quick look around at other code that might be doing the same thing. One instance of a hack is just a hack, but two calls into the same hack establishes a new API
It solves a generic problem, namely that some core VM structures were being zeroed multiple times. By fixing this "bug" these core VM routines could be reused by memory hotplug. Win-win patches are much less controversial.
Avoid copying and pasting code. If you need a bit of code out of the middle of another function, move it out of there and into a common, global function, call it from the old place, and your new code.
Break patches up
See 3) in SubmittingPatches
Especially break things up that are just icing on the cake. If a bit of your patch is "just a cleanup" or "just an optimization" but isn't part of the core work, separate it. Many times, the core functionality of your patch will be accepted without the contentious extra bits.
It has to work everywhere
This may seem daunting: you're new to kernel development, and your patch is required to work on every architecture, 32-bit, 64-bit, big-endian, little-endian, Alpha, MIPS, even Sparc64. However, Linux has the infrastructure to do this quite easily. If someone gives you a suggestion to make it more portable, use it, even if you don't think it's needed.
It helps if you bring something else to the table
Things beyond the code itself are important
If you are not a native english speaker, seek someone out who is to help you review. Sometimes, there are subtle language implications from variable names, or other things that are hard to pick out if you are not a native speaker.