On Sat, 16 Jun 2007, Jan Engelhardt wrote:
> >
> >Heh. Actually, Linux maintainers have generally very consciously _avoided_
> >trying to "enforce" coding style issues.
>
> Really? "it's not going to be merged unless you turn all uint32_t into
> u_int32_t" is a paraphrased variant of what I was told this month.
I suspect different maintainers are hung up on different things, so yes,
certain things are more likely to carry red flags, and it also depends on
the patch.
For example, if I get a patch for something that is a whole driver, I
generally think that while I *prefer* to see it follow the kernel coding
style, I also expect that the person who sends me the driver is the one
who is going to maintain it in the future, and thus his personal coding
style preferences will override any but the strongest objections.
(So if somebody sends me a FSF-style "tabs are two characters, and
functions must be longer than 300 lines" mess, I generally would prefer to
not take it at all, but for some really obscure driver I might not care).
In contrast, if a patch modifies code that somebody else really will end
up touching in the future (maybe not "maintain", but maybe there is no
single and obvious maintainer), it had better match the code around it.
So to take your particular example: For me, "uint32_t" is certainly better
than "u_int32_t" (and there's seven times as many of the former as the
latter in the kernel), but for code _I_ would touch, I'd actually prefer
the Linux internal "__u32"/"u32", which have no question about what their
user-space visibility is (ie "__u32" is *always* ok in a header file that
is visible to user space).
But would I make it a huge issue? Not personally. So it will depend on the
maintainer.
(Personally, I think the "small functions, no deep levels of indentation,
and tabs are 8 characters wide" are the most important part by far. But I
do actually end up complaining about function naming etc too).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
