Hi again, everybody...
Let's discuss a bit about the common mistakes when preparing patches to send to LKML.
- White spaces:
Check and re-check if your patches have any extra white-spaces. Linux's subsystem maintainers DO NOT like trailing white-spaces.
You can add this to you .vimrc in order to "detect" white-spaces. They'll be marked in red:highlight RedundantWhitespace ctermbg=red guibg=red
match RedundantWhitespace /\s\+$\| \+\ze\t/ - Bad indentation:
Always follow the correct indentation defined in Documentation/CodingStyle. Never apply your own coding style. If you're unsure about how to indent you code, before committing, run the Lindent script in scripts/Lindent - CaMeLcAsE definitions:
Don't use CaMeLcAsE, it will never get accepted. Separate words with _. - Ugly type-casts:
Type casts are ugly in kernel, whenever you can find a way to do it better. For instance, use container_of() to avoid type-casts. - Missing Files:
Before committing your changes check and re-check if you've added all the files to the commit-ish. If you leave a file out of the patch it won't get accepted since it won't work fine. - Including files that don't belong that patch:
When producing patches you need to be aware about what are you really doing. Are you bug fixing or implementing better logic?
When doing both, put them in separate patches to avoid confusing the community about your changes. - Huge Patch:
If your patch is bigger than 40k, maybe is time to break it into a patch series. Keep that in mind. - Sending more than 15 patches at once:
Try not to send more than 15 patches at once, you send patches whenever you want so when you get one bug fixed, you can release that patch right away. - HTML'd email:
ONLY use plain text email. Never use html formated mails. Remeber: we use mutt. - Mails with MIME, links, compression and/or attachments:
Patches should be inline, never attached. If you attach a patch, it become difficult to comment your code. Also, don't use MIME, don't use links (at least it's not usual) and never use compression. - #ifdefs are UGLY:
There are lots of ways to avoid using #ifdefs, you should know about it. Read Documentation/SubmittingPatches to check the most common ways to achieve that. - Use static inline instead of MACROS:
When you need to use some function in certain cases is better to use static inline instead of MACROS. Let's check an example:#ifdef CONFIG_BLABLA
extern int foo(int bar);
#else
static inline int foo(int bar)
{
return 0;
}
#endifThis is right way!
#ifdef CONFIG_BLABLA
extern int foo(int bar);
#else
#define foo(b) NULL
#endif