'files' will be immediately reassigned. 'f_flags' and 'file' will be
overwritten in the if{} or seq_show() directly exits with an error.
so we don't need to consume CPU resources to initialize them.
Signed-off-by: Kaitao Cheng <[email protected]>
---
v2 ChangeLog:
1. Fix some commit message
2. Remove unnecessary f_flags initialization
fs/proc/fd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/proc/fd.c b/fs/proc/fd.c
index 81882a13212d..d3854b76e95e 100644
--- a/fs/proc/fd.c
+++ b/fs/proc/fd.c
@@ -19,9 +19,9 @@
static int seq_show(struct seq_file *m, void *v)
{
- struct files_struct *files = NULL;
- int f_flags = 0, ret = -ENOENT;
- struct file *file = NULL;
+ struct files_struct *files;
+ int f_flags, ret = -ENOENT;
+ struct file *file;
struct task_struct *task;
task = get_proc_task(m->private);
--
2.20.1
> 'files' will be immediately reassigned. 'f_flags' and 'file' will be
> overwritten in the if{} or seq_show() directly exits with an error.
> so we don't need to consume CPU resources to initialize them.
I suggest to improve also this change description.
* Should the mentioned identifiers refer to variables?
* Will another imperative wording be preferred?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=b791d1bdf9212d944d749a5c7ff6febdba241771#n151
* I propose to extend the patch a bit more.
How do you think about to convert the initialisation for the variable “ret”
also into a later assignment?
Regards,
Markus
On Fri, Jun 12, 2020 at 06:45:57PM +0200, Markus Elfring wrote:
> > 'files' will be immediately reassigned. 'f_flags' and 'file' will be
> > overwritten in the if{} or seq_show() directly exits with an error.
> > so we don't need to consume CPU resources to initialize them.
>
> I suggest to improve also this change description.
>
> * Should the mentioned identifiers refer to variables?
>
> * Will another imperative wording be preferred?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=b791d1bdf9212d944d749a5c7ff6febdba241771#n151
>
> * I propose to extend the patch a bit more.
> How do you think about to convert the initialisation for the variable “ret”
> also into a later assignment?
Please stop commenting on people's changelogs. You add no value.
>>> 'files' will be immediately reassigned. 'f_flags' and 'file' will be
>>> overwritten in the if{} or seq_show() directly exits with an error.
>>> so we don't need to consume CPU resources to initialize them.
>>
>> I suggest to improve also this change description.
>>
>> * Should the mentioned identifiers refer to variables?
>>
>> * Will another imperative wording be preferred?
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=b791d1bdf9212d944d749a5c7ff6febdba241771#n151
>>
>> * I propose to extend the patch a bit more.
>> How do you think about to convert the initialisation for the variable “ret”
>> also into a later assignment?
>
> Please stop commenting on people's changelogs. You add no value.
Would you like to clarify concrete software development ideas?
Regards,
Markus
>>> 'files' will be immediately reassigned. 'f_flags' and 'file' will be
>>> overwritten in the if{} or seq_show() directly exits with an error.
>>> so we don't need to consume CPU resources to initialize them.
>>
>> I suggest to improve also this change description.
>>
>> * Should the mentioned identifiers refer to variables?
>>
>> * Will another imperative wording be preferred?
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=b791d1bdf9212d944d749a5c7ff6febdba241771#n151
>>
>> * I propose to extend the patch a bit more.
>> How do you think about to convert the initialisation for the variable “ret”
>> also into a later assignment?
>
> Please stop commenting on people's changelogs. You add no value.
Would you like to clarify concrete software development ideas?
Regards,
Markus
On Fri, Jun 12, 2020 at 07:03:49PM +0200, Markus Elfring wrote:
> >>> 'files' will be immediately reassigned. 'f_flags' and 'file' will be
> >>> overwritten in the if{} or seq_show() directly exits with an error.
> >>> so we don't need to consume CPU resources to initialize them.
> >>
> >> I suggest to improve also this change description.
> >>
> >> * Should the mentioned identifiers refer to variables?
> >>
> >> * Will another imperative wording be preferred?
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=b791d1bdf9212d944d749a5c7ff6febdba241771#n151
> >>
> >> * I propose to extend the patch a bit more.
> >> How do you think about to convert the initialisation for the variable “ret”
> >> also into a later assignment?
> >
> > Please stop commenting on people's changelogs. You add no value.
>
> Would you like to clarify concrete software development ideas?
Yes. Learn something deeply, then your opinion will have value.
>> Would you like to clarify concrete software development ideas?
>
> Yes. Learn something deeply, then your opinion will have value.
The presented suggestions trigger different views by involved contributors.
In which directions can the desired clarification evolve?
How do you think about further function design alternatives?
Regards,
Markus
On Fri, Jun 12, 2020 at 08:22:43PM +0200, Markus Elfring wrote:
> >> Would you like to clarify concrete software development ideas?
> >
> > Yes. Learn something deeply, then your opinion will have value.
>
> The presented suggestions trigger different views by involved contributors.
Most of the views I've heard are "Markus, go away". Do you not hear these
views?
> In which directions can the desired clarification evolve?
You could try communicating in a way that the rest of us do. For
example, instead of saying something weird about "collateral evolution"
you could say "I think there's a similar bug here".
> How do you think about further function design alternatives?
Could you repeat that in German? I don't know what you mean.
>> The presented suggestions trigger different views by involved contributors.
>
> Most of the views I've heard are "Markus, go away".
> Do you not hear these views?
I notice also this kind of feedback.
The clarification is still evolving for these concerns and communication difficulties.
I suggest to take another look at published software development activities.
>> In which directions can the desired clarification evolve?
>
> You could try communicating in a way that the rest of us do.
I got also used to some communication styles.
I am curious to find the differences out which hinder to achieve a better
common understanding.
> For example, instead of saying something weird about "collateral evolution"
> you could say "I think there's a similar bug here".
* Why do you repeat this topic here?
* Do try to distract from implementation details which were pointed out
by two developers for this patch?
>> How do you think about further function design alternatives?
>
> Could you repeat that in German? I don't know what you mean.
I imagine that you could know affected software aspects better.
Regards,
Markus
On Fri, Jun 12, 2020 at 08:43:41PM +0200, Markus Elfring wrote:
> >> The presented suggestions trigger different views by involved contributors.
> >
> > Most of the views I've heard are "Markus, go away".
> > Do you not hear these views?
>
> I notice also this kind of feedback.
> The clarification is still evolving for these concerns and communication difficulties.
>
> I suggest to take another look at published software development activities.
Do you collateral evolution in the twenty?
> I got also used to some communication styles.
> I am curious to find the differences out which hinder to achieve a better
> common understanding.
My quantum tunnelling eases the mind.
> > For example, instead of saying something weird about "collateral evolution"
> > you could say "I think there's a similar bug here".
>
> * Why do you repeat this topic here?
* Can communication be achieved?
* Will you twice the program?
> >> How do you think about further function design alternatives?
> >
> > Could you repeat that in German? I don't know what you mean.
>
> I imagine that you could know affected software aspects better.
Murph had other ideas.
>> I suggest to take another look at published software development activities.
>
> Do you collateral evolution in the twenty?
Evolutions and software refactorings are just happening.
Can we continue to clarify the concrete programming items
also for a more constructive review of this patch variant?
Regards,
Markus
On Fri, Jun 12, 2020 at 09:00:14PM +0200, Markus Elfring wrote:
> >> I suggest to take another look at published software development activities.
> >
> > Do you collateral evolution in the twenty?
>
> Evolutions and software refactorings are just happening.
> Can we continue to clarify the concrete programming items
> also for a more constructive review of this patch variant?
Generationally, pandemics are an investment opportunity for the
likeminded. Talking about human nature is the ultimate world view for
the proletariat.
>> I suggest to take another look at published software development activities.
>
> Do you collateral evolution in the twenty?
Evolutions and software refactorings are just happening.
Can we continue to clarify the concrete programming items
also for a more constructive review of this patch variant?
Regards,
Markus
On Fri, Jun 12, 2020 at 09:00:14PM +0200, Markus Elfring wrote:
> >> I suggest to take another look at published software development activities.
> >
> > Do you collateral evolution in the twenty?
>
> Evolutions and software refactorings are just happening.
> Can we continue to clarify the concrete programming items
> also for a more constructive review of this patch variant?
The really shocking part is that apparently this thing is _not_ a bot -
according to the people who'd been unfortunate enough to meet it, it's
hosted by wetware and behaviour is the same face-to-face...
I'm still not convinced that it's not a sociology student collecting
PhD material, though - something around strong programme crowd,
with their religious avoidance of learning the subject matter, lest
it taints their "research"...
On Fri, Jun 12, 2020 at 06:45:57PM +0200, Markus Elfring wrote:
> > 'files' will be immediately reassigned. 'f_flags' and 'file' will be
> > overwritten in the if{} or seq_show() directly exits with an error.
> > so we don't need to consume CPU resources to initialize them.
>
> I suggest to improve also this change description.
>
> * Should the mentioned identifiers refer to variables?
>
> * Will another imperative wording be preferred?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=b791d1bdf9212d944d749a5c7ff6febdba241771#n151
>
> * I propose to extend the patch a bit more.
> How do you think about to convert the initialisation for the variable “ret”
> also into a later assignment?
>
> Regards,
> Markus
Hi,
This is the semi-friendly patch-bot of Greg Kroah-Hartman.
Markus, you seem to have sent a nonsensical or otherwise pointless
review comment to a patch submission on a Linux kernel developer mailing
list. I strongly suggest that you not do this anymore. Please do not
bother developers who are actively working to produce patches and
features with comments that, in the end, are a waste of time.
Patch submitter, please ignore Markus's suggestion; you do not need to
follow it at all. The person/bot/AI that sent it is being ignored by
almost all Linux kernel maintainers for having a persistent pattern of
behavior of producing distracting and pointless commentary, and
inability to adapt to feedback. Please feel free to also ignore emails
from them.
thanks,
greg k-h's patch email bot
> 'files' will be immediately reassigned. 'f_flags' and 'file' will be
> overwritten in the if{} or seq_show() directly exits with an error.
> so we don't need to consume CPU resources to initialize them.
How do you think about to reduce the scope for four local variables
in this function implementation?
https://refactoring.com/catalog/reduceScopeOfVariable.html
Regards,
Markus