Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

> How many times have I told you to include the reason for your patches > in your proposed commit message? Will it be useful to look again at the involved circumstances? > Too often. Did I answer any concerns partly? > Many people do not know that a generic kmalloc does a dump_stack() on

Re: kernel/module: Delete an error message for a failed memory allocation in add_module_usage()

>>> Something like: >>> >>> "because there is a dump_stack() done on allocation failures >>> without __GFP_JNOWARN" >> >> How do you think about to convert such a description into a special format >> for further reference documentation? > > I think it's a bad idea if it's a "special" format.

Re: kernel/module: Delete an error message for a failed memory allocation in add_module_usage()

Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring >>> >>> Applied to modules-next, thanks. >> >> Thanks for your acceptance of this

Re: kernel/module: Delete an error message for a failed memory allocation in add_module_usage()

>> This is a small allocation so it can't fail in current kernels.  I can't >> imagine a situation where this could fail and it wasn't dead easy to >> debug.  Most modules are loaded at boot so it's not likely to fail, but >> if it did, it would be easy to reproduce.  If it's not loaded at boot >>

Re: [PATCH 4/4] char/snsc: Delete unnecessary braces in five functions

>> /* ...or if we want to block, then do so here */ >> -if (down_interruptible(>sd_wbs)) { >> +if (down_interruptible(>sd_wbs)) >> /* something went wrong with wait */ >> return -ERESTARTSYS; >> -} >> }

Re: Support for advanced documentation around data type definitions

Hello, Do you find it relevant to clarify the following details? Some data type definitions are provided by Linux source files. How would you like to see them represented in the documentation formats which are generated by the Sphinx software? Regards, Markus -- To unsubscribe from this list:

Support for advanced documentation around data type definitions

Hello, Some data type definitions are provided by Linux source files. How would you like to see them represented in the documentation formats which are generated by the Sphinx software? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a

[PATCH] scripts/coccicheck: Update reference for the corresponding documentation

From: Markus Elfring Date: Fri, 7 Oct 2016 16:06:15 +0200 Use the current name (in a comment at the beginning of this script) for the file which was converted to the documentation format "reStructuredText" in August 2016. Fixes:

Re: docs: Fixing "sphinxify coccinelle.txt"?

>>> Information from a commit like "docs: sphinxify coccinelle.txt and add it >>> to dev-tools" caught also my software development attention. >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/coccinelle.txt?id=4b9033a33494ec9154d63e706e9e47f7eb3fd59e >>> >>>

Re: docs: Fixing "sphinxify coccinelle.txt"?

>> Information from a commit like "docs: sphinxify coccinelle.txt and add it >> to dev-tools" caught also my software development attention. >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/coccinelle.txt?id=4b9033a33494ec9154d63e706e9e47f7eb3fd59e >> >> Did

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

> If you continue discussing after that point, I guess that such a condition is not needed. > then you make a clear statement that it isn't an accident. I hope that most of my software development activities are not "an accident". Is the intent for any update suggestion (like the renaming of a

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

> I don't like out labels, but that's my opinion. Thanks for this acknowledgement that you have still got a special opinion about such an identifier. > There is nothing in CodingStyle which says you can't do it. Does the terse description there try to suggest also to choose better identifiers

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

> When someone tells you that you are wasting their time, This information can be useful to some degree > then that is not a subject for further discussion. I got an other impression. I guess that there are constraints for such a response which can become interesting for further

Re: md/dm-crypt: Rename a jump label in crypt_message() ?

> Again, I wrote the paragraph in CodingStyle. This is obvious from the corresponding commit "add some more error handling guidelines" (ea04036032edda6f771c1381d03832d2ed0f6c31 on 2014-12-02). > I just said that it's a good idea to think about label names I agree also to such a desire. >

Re: GPU-DRM-nouveau: Delete unnecessary braces

> The original style was correct, the new style is wrong. I find your feedback interesting for further clarifications. > Multi-line indents get curly braces for readability. How do you think about to transform such an information into an official specification for the the document

Re: samples: move auxdisplay example code from Documentation

> Documentation/auxdisplay/cfag12864b needs to be updated to reflect the new > home for the program (which probably does belong in samples/). > > I wonder if these programs need MAINTAINERS entries too? Do you find any more update suggestions interesting around this software module?

Re: clk/Renesas-MSTP: Rename jump labels in cpg_mstp_attach_dev()

> "Choose label names which say what the goto does or why the goto exists." > > I prefer the "why" over the "what". Does your opinion indicate also that you would appreciate another adjustment around the quoted sentence from "Chapter 7: Centralized exiting of functions" of the document

Re: virtio_blk: Less function calls in init_vq() after error detection

>> drivers/block/virtio_blk.c | 22 +- >> 1 file changed, 17 insertions(+), 5 deletions(-) > > Can't you see from this diffstat that the patch actually seems to makes > the code more complex? I find that the repeated usage of a bit more error handling code is almost

Re: Clarification for source code formatting around jump labels

>> I am just curious on how much further software development "fun" the recent >> update >> by a topic like "CodingStyle: Clarify and complete chapter 7" will trigger. > > I don't want to drag this thread onwards for (way) too long, but clearly "it > is > advised to indent labels with a single

Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

> It's not because I find improvements "uncomfortable", but rather it's > because your changes are not seen as improvements in the first place. What is your software development opinion for the update step "[1/4] sparc: bpf_jit: Use kmalloc_array() in bpf_jit_compile()" from this small patch

Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=865a1caa4b6b886babdd9d67e7c3608be4567a51 > > You seem to lack understanding of the difference between absolute > requirements and "advice". > > As Sparc maintainer I can choose to not take

Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

>> NAK, just noise. > > And frankly I hate that leading space. Would you like to comment the recent update of the document "CodingStyle" any more? https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=865a1caa4b6b886babdd9d67e7c3608be4567a51

Re: cris-cryptocop: Apply another recommendation from "checkpatch.pl"

>>> There is plenty of room for at least &(*pj)->iop on the line before. >> >> This is true. - Do you prefer an other indentation approach here? > > Very much. Most of the kernel code puts as much information on a line as > possible, unless there is a reason to do otherwise. Then more of the

Re: ia64/mm/tlb: Delete unnecessary braces

>arch/ia64/mm/tlb.c: In function 'ia64_global_tlb_purge': >>> arch/ia64/mm/tlb.c:247:5: warning: suggest explicit braces to avoid >>> ambiguous 'else' [-Wparentheses] > if (mm != active_mm) > ^ Does this message from the compiler mean that there are a few corresponding details

Re: CodingStyle: Clarify and complete chapter 7

>>> A common type of bug to be aware of is "one err bugs" which look like this: >>> >>> -err: >>> + err: >>> kfree(foo->bar); >>> kfree(foo); >>> return ret; >>> >>> The bug in this code is that on some exit paths "foo" is NULL. Normally >>> the >> >>

Re: staging: ks7010: Rename jump labels

>> Would you like to support the renaming of a label like "error_out1" >> (in the function "ks7010_upload_firmware" for example)? > > They should be renamed too. Anything using numbers instead of explicit Interesting … > Anything using numbers instead of explicit labels should be updated.

Re: staging: ks7010: Rename jump labels

>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl?id=92d21ac74a9e3c09b0b01c764e530657e4c85c49#n4326 > > "#goto labels aren't indented, allow a single space however" > > Can't be clearer :-) Should such information from a comment in this script be also