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

2017-10-19 Thread SF Markus Elfring 
>>> 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.

Will it be nice to represent corresponding details as a better
“restructured text”?


> Always write _why_ some code is being changed.
> 
> People could read the commit descriptions and would not need
> to take extra time to lookup external references.

I would appreciate if I could copy a widely accepted explanation.


> Maybe add something like
> "see (commit  or )" for additional details"

Are there any related extensions possible besides other background information?
Link: 
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-10-19 Thread Joe Perches 
On Thu, 2017-10-19 at 13:35 +0200, SF Markus Elfring wrote:
> > > > > Omit an extra message for a memory allocation failure in this 
> > > > > function.
> > > > > 
> > > > > This issue was detected by using the Coccinelle software.
[]
> > > Do you see any need that I should extend subsequent commit messages
> > > for this software transformation pattern?
> > 
> > Add a description of _why_ this is being done.
> > 
> > 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.

Always write _why_ some code is being changed.

People could read the commit descriptions and would not need
to take extra time to lookup external references.

Maybe add something like
"see (commit  or )" for additional details"

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-10-19 Thread SF Markus Elfring 
 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 update suggestion after a bit of 
>> clarification.
>>
>> Do you see any need that I should extend subsequent commit messages
>> for this software transformation pattern?
> 
> Add a description of _why_ this is being done.
> 
> 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?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-10-19 Thread SF Markus Elfring 
>> 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
>> it's probably really easy to tell which module we're loading.
> 
> Yeah, good points. And on second thought, we normally don't print
> warnings for every small alloc failure in the kernel anyway (that
> would be utterly superfluous), the error code itself is sufficient.
> And in the module loader this seems to be the only printk out of the
> dozen alloc calls we do, so I'm OK with removing this one.

Thanks for your constructive feedback.

Can it help to improve the corresponding documentation for Linux
programming interfaces a bit more?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html