On Tue, Sep 18, 2018 at 08:01:22PM -0400, valdis.kletnieks@vt.edu wrote:

On Wed, 19 Sep 2018 09:35:36 +1000, "Tobin C. Harding" said:

...

Hi,

I'm after some advice from those more experienced with [kernel] development please.

What systems do you have in place to help catch mistakes? In other words; what processes do you use when coding and submitting patches to help eliminate simple mistakes?

Same way you verify it for any other large programming project.

'make clean && make && make install && shutdown -r now'

1) Verify no compile errors.

2) Verify no unexplained compile warnings. gcc *does* screw up and whine about things incorrectly on occasion because it doesn't know everything - "variable may be used uninitialized" is a famous one, usually emitted because there's program logic it can't see. For instance, code like:

int oddball; for (i=0;i<foo;i++) { if (wombat > 5) oddball = 7; if (frobozz) quux = oddball; }

and there's a reason known to programmer but not compiler that guarantees that wombat > 5 will always happen at least once before frobozz becomes true.

But in general, unless you can *prove* the compiler is false-positive on a warning, fix the warning. ;)

2a) (optional) Install 'sparse' and do a 'make C=2' and see if that complains about anything that gcc didn't...

3) Test that it actually boots and does whatever your patch is supposed to do.

See? And here you thought it was difficult :)

Thanks for your response Valdis (especially the wombat reference). I'm talking though about more brain dead mistakes like: - Muddling up changes between patches when rebasing - Missing an instance of a series of the same changes (usually because you did 100 of them and one slipped past when viewing the diff) Things that don't make the compiler or static analysis complain. I made an improvement on my method today and that was to review patch sets [almost] ready for submission first thing in the day so your eyes/brain is fresh. These sort of 'soft' ideas I'm after please. I'm sure the old fellas have a bunch of them that they do unconsciously but any that any one can think of would be great to hear. thanks, Tobin.

On Tue, Sep 18, 2018 at 10:01:19PM -0400, Cindy-Sue Causey wrote:

On 9/18/18, Tobin C. Harding <me@tobin.cc> wrote:

...

Hi,

I'm after some advice from those more experienced with [kernel] development please.

What systems do you have in place to help catch mistakes? In other words; what processes do you use when coding and submitting patches to help eliminate simple mistakes? So far my best method is getting a patch [set] ready then waiting until the next day before reviewing the set and submitting. I am facing an issue where by when doing (less than super interesting) large patch sets (like docs fixes) that by the time I get to the final review my eyes glaze over and I'm still missing mistakes.

My future maintainers will thank you ;)

For the docs part of what you're doing, *I* read what I write out loud and deliberately very slowly so that I actually see each word. I *empathize* with you. I experience something similar regarding my often long winded emails. I'll proofread literally 10 or 15 times then see that one last mistake...

That I MISSED... as the email is disappearing out of sight because it has just been sent to a listserv. :D

Reading out loud **slower** than I normally would helps me see AND hear mistakes. If I read at a normal speed, even if I do so out loud, it's some kind of a Human nature thing that I'll keep reading my mistakes wrongly by mentally "glossing over" those mistakes instead of seeing them for the oopsies they are. Instead of catching those mistakes and fixing them, I just keep saying them WRONG out loud over and over (AND over) if I do so at a normal conversational speaking speed. :))

Have fun!

Cindy :)

Awesome, thanks Cindy. Just the sort of tip I was after. thanks, Tobin.