On Thursday 2012-08-02 22:22, Sam Ravnborg wrote: >> On Friday 2012-07-27 12:34, Sam Ravnborg wrote: >> >> +#ifndef _VMCI_COMMONINT_H_ >> >> +#define _VMCI_COMMONINT_H_ >> >> + >> >> +#include <linux/printk.h> >> >> +#include <linux/vmw_vmci_defs.h> >> > >> >Use inverse chrismas tree here. >> >Longer include lines first, and soret alphabetically when >> >lines are of the same length. >> >> So that's where unreadable include lists come from. >> Depth-first lexicographically-sorted is a lot less hassle, >> especially when it comes to merging patches that each >> add one different include. >This is applied in many parts of the kernels and has some benefits: >- easy to spot duplicates >- clash is less likely when two commit adds includes Sorting already addresses the two, the christmas thing (for files in a single dir) seems like adding no extra value. >>>The kernel types are u32 not uint32_t - these types belongs in user-space. >Found the following somewhere on the net: > >| - the kernel should not depend on, or pollute user-space naming. >| YOU MUST NOT USE "uint32_t" when that may not be defined, and >| user-space rules for when it is defined are arcane and totally >| arbitrary. I can see the reasoning for header files, but it seems irrelevant for code, in particular .c files, that never practically get exposed to userspace. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
