Here is an example that I believe is more than just "being far too blunt"[0], it's not the worst example I can remember but it is the first one I found. In my opinion his major issue is that he grandstands, he goes beyond being just blunt and becomes unnecessarily derogatory. If his issue was with being too blunt (and I suspect you'll find that most people don't consider being too blunt to be that much of an issue compared to his other faults) that email would look something like this:
> The conflict I get is due to stupid new gcc header file crap. But the
> reason I'm rejecting this is that I just don't think it brings in any
> positive value.
> This is the old code in net/ipv6/ip6_output.c:
> mtu -= hlen + sizeof(struct frag_hdr);
> and this is the new "improved" code that uses fancy stuff that wants
> magical built-in compiler support and has silly wrapper functions for
> when it doesn't exist:
> if (overflow_usub(mtu, hlen + sizeof(struct frag_hdr), &mtu) ||
> mtu <= 7)
> goto fail_toobig;
> The above code generates shit code
> <insert evidence that generated code is shit>
> and it's a lot more difficult for people to read.
> The code could easily have been done with just a single and
> understandable conditional, and the compiler would actually have
> generated better code, and the code would look better and more
> understandable.
> <evidence of this statement too>
> Why is this not
> if (mtu < hlen + sizeof(struct frag_hdr) + 8)
> goto fail_toobig;
> mtu -= hlen + sizeof(struct frag_hdr);
> which is the same number of lines, doesn't use helper functions that
> most people are unfamiliar with, and is much more obvious what it
> actually does.
> The second more obvious version is easier to read and understand. Does
> anybody disagree with this?
> Obviously you still could have overflow issues if the whole "hlen +
> xyz" expression overflows, but the "overflow_usub()" code had that
> too. So if that's the reason that this change was introduced then
> it hasn't actually fixed anything.
> I really do feel like this code was designed to use that
> new "overflow_usub()" code, it seems to be an excuse to use that
> function. Am I missing something here?
> Just to be clear I will always try to make sure that code which offers no
> positive value does not make it into the code base, regardless of where
> in the code it's being added.
> Linus
This is still just as blunt (I do think this would be more effective if it wasn't as blunt, I just wanted to try to show that being blunt wasn't the main issue), but it doesn't have the unnecessary grandstanding and derogatory comments. The main problem with the was Linus used to conduct himself is that he puts people on the defensive, and when people are on the defensive they have a much harder time admitting that they were wrong or learning anything.
I don't actually expect Linus to come back any less blunt, I expect him to come back less aggressive and derogatory.
Here is an example that I believe is more than just "being far too blunt"[0], it's not the worst example I can remember but it is the first one I found. In my opinion his major issue is that he grandstands, he goes beyond being just blunt and becomes unnecessarily derogatory. If his issue was with being too blunt (and I suspect you'll find that most people don't consider being too blunt to be that much of an issue compared to his other faults) that email would look something like this:
> The conflict I get is due to stupid new gcc header file crap. But the > reason I'm rejecting this is that I just don't think it brings in any > positive value.
> This is the old code in net/ipv6/ip6_output.c:
> mtu -= hlen + sizeof(struct frag_hdr);
> and this is the new "improved" code that uses fancy stuff that wants > magical built-in compiler support and has silly wrapper functions for > when it doesn't exist:
> if (overflow_usub(mtu, hlen + sizeof(struct frag_hdr), &mtu) || > mtu <= 7) > goto fail_toobig;
> The above code generates shit code
> <insert evidence that generated code is shit>
> and it's a lot more difficult for people to read.
> The code could easily have been done with just a single and > understandable conditional, and the compiler would actually have > generated better code, and the code would look better and more > understandable.
> <evidence of this statement too>
> Why is this not
> if (mtu < hlen + sizeof(struct frag_hdr) + 8) > goto fail_toobig; > mtu -= hlen + sizeof(struct frag_hdr);
> which is the same number of lines, doesn't use helper functions that > most people are unfamiliar with, and is much more obvious what it > actually does.
> The second more obvious version is easier to read and understand. Does > anybody disagree with this?
> Obviously you still could have overflow issues if the whole "hlen + > xyz" expression overflows, but the "overflow_usub()" code had that > too. So if that's the reason that this change was introduced then > it hasn't actually fixed anything.
> I really do feel like this code was designed to use that > new "overflow_usub()" code, it seems to be an excuse to use that > function. Am I missing something here?
> Just to be clear I will always try to make sure that code which offers no > positive value does not make it into the code base, regardless of where > in the code it's being added.
> Linus
This is still just as blunt (I do think this would be more effective if it wasn't as blunt, I just wanted to try to show that being blunt wasn't the main issue), but it doesn't have the unnecessary grandstanding and derogatory comments. The main problem with the was Linus used to conduct himself is that he puts people on the defensive, and when people are on the defensive they have a much harder time admitting that they were wrong or learning anything.
I don't actually expect Linus to come back any less blunt, I expect him to come back less aggressive and derogatory.
[0]: http://lkml.iu.edu/hypermail/linux/kernel/1510.3/02866.html