3 ms·

Same for the original patch from the mailing conversation above. The original results in (reformatted) #ifdef CONFIG_PPC32 data = ((unsigned int )ch

by micw 3y ago

Same for the original patch from the mailing conversation above. The original results in (reformatted) #ifdef CONFIG_PPC32 *data = ((unsigned int *)child->thread.fp_state.fpr)[FPRINDEX(index)]; #else flush_fp_to_thread(child); if (fpidx < (PT_FPSCR - PT_FPR0)) memcpy(data, &child->thread.TS_FPR(fpidx), sizeof(long)); else *data = child->thread.fp_state.fpscr; #endif while the final patch is flush_fp_to_thread(child); if (fpidx < (PT_FPSCR - PT_FPR0)) { if (IS_ENABLED(CONFIG_PPC32)) *data = ((u32 *)child->thread.fp_state.fpr)[fpidx]; else memcpy(data, &child->thread.TS_FPR(fpidx), sizeof(long)); } else *data = child->thread.fp_state.fpscr; So there is actually a difference between both solutions. The original has neither the flush_fp_to_thread not the else-condition for the PPC32 architecture. I cannot say which is right/wrong/better but it's definitively a different result.

l-albertovich 3y ago
There's a clear logical difference in those two patches and I can't blame the maintainer for going with his version. Attribution should be given though, regardless of the bug OPs patch introduced the actual line that fixes the issue is clearly the same thing with the appropriate coding style. As a maintainer, I can understand his reasoning but TBH it would've been easier and more respectful to just reply with the proper code snippet, having the contributor submit it (if he agreed) and then giving them credit. Honestly, the comment section of this thread sucks, the level of self righteousness, "aggression" and gatekeeping is ridiculously uncalled for.
- rolandog 3y ago
  Agreed. You basically get paid in reputation, trustworthiness, and maybe even beer/brownie/pizza points. I also think that public interactions offer a preview of how easy (or difficult) it will be to work with someone on a project... we're not experts on every domain of knowledge, so the best bet is to approach interactions with a bit of humility and respect. If this were an AITA reddit thread, ESH (a little bit).
deleted 3y ago
[deleted]

Same for the original patch from the mailing conversation above. The original results in (reformatted) #ifdef CONFIG_PPC32 *data = ((unsigned int *)ch

by micw 3y ago

l-albertovich 3y ago

There's a clear logical difference in those two patches and I can't blame the maintainer for going with his version. Attribution should be given though, regardless of the bug OPs patch introduced the actual line that fixes the issue is clearly the same thing with the appropriate coding style. As a maintainer, I can understand his reasoning but TBH it would've been easier and more respectful to just reply with the proper code snippet, having the contributor submit it (if he agreed) and then giving them credit. Honestly, the comment section of this thread sucks, the level of self righteousness, "aggression" and gatekeeping is ridiculously uncalled for.

rolandog 3y ago
Agreed. You basically get paid in reputation, trustworthiness, and maybe even beer/brownie/pizza points. I also think that public interactions offer a preview of how easy (or difficult) it will be to work with someone on a project... we're not experts on every domain of knowledge, so the best bet is to approach interactions with a bit of humility and respect. If this were an AITA reddit thread, ESH (a little bit).

deleted 3y ago

[deleted]