On Thu, 16 Nov 2017 18:48:43 +0100, SF Markus Elfring wrote: > > >> Two update suggestions were taken into account > >> from static source code analysis. > > > > Markus, I'd apply this kind of patches only when they are really > > tested on the hardware, > > I can not test all software and hardware combinations (so far) > for which I dare to show change possibilities. > > > > or they were converted systematically by a script like spatch. > > There is a general source code transformation pattern involved. > So I find that it is systematic. > > But I did not dare to develop a script variant for the semantic patch > language (Coccinelle software) which can handle all special use cases > as a few of them are already demonstrated in this tiny patch series. Then you're doing everything by hands, and can be wrong -- that's the heart of the problem. The risk is bigger than the merit by applying the patch. So, just prove that your patch doesn't break anything. Doesn't matter whether it's a test with real hardware or with systematic checks. Once when it's confirmed, we can apply it. A very simple rule, and this will be valid for most of other subsystems, too. thanks, Takashi > > > > The reason is that you might break something > > There are the usual software development risks. > > > > (and you already broke things in the past). > > I presented also some improvable update suggestions. > > Another look on the corresponding circumstances might be interesting > for further clarification. > > > > The merit by such a patch is negligible in comparison of the risk of breakage. > > I imagine that you might like a small object code reduction also for > this software module. > > > > These codes aren't too bad without fixing, after all; > > everyone can read it pretty well as is. > > The script "checkpatch.pl" points implementation details out for > further considerations. > > > > If these patches were tested on a real hardware, > > I assume that this aspect can become a big challenge. > > > > or at least on VM, so that you can show that they don't break anything, > > Which test results would you trust (from me)? > > > > I'll happily apply them for the next (4.16) kernel. > > Thanks for your general offer. > > > > Or, if you're really working on other real changes > > I would find a bit more efficient exception handling useful. > > > > (no cosmetic coding style fixes nor the code shuffling, > > I propose to apply also corresponding checkpatch cosmetic. > > > > but fixing a real bug) > > I am trying to adjust the software situation a bit more for better > run time characteristics. > > > > *and* such a cleanup is mandatory as preliminary, it can be accepted, too. > > There are change combinations needed for the proposed software > design direction. > Can you see positive effects here? > > Regards, > Markus > -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
