From: SF Markus Elfring
Date: Sat, 20 Dec 2014 15:45:32 +0100
> I hope that you will find a bit time and patience again
> to clarify affected implementation details in a safer and
> unambiguous way.
Sorry, another developer will have to hold your hand, as I
said I already invested too much time
> I think what David said was pretty clear: If you see code like the above
> there is no need to refactor it.
I can understand this view in principle.
> That does not mean that this is the _preferred_ way of error handling.
Can your feedback help in the clarification of suggestions around
my up
Hi Markus,
On 20.12.2014 15:45, SF Markus Elfring wrote:
>> I'm saying to leave the code alone.
>
> Do I need to try another interpretation out for your feedback?
>
>
>> If it goes:
>>
>> var = foo_that_returns_ptr_err()
>> if (IS_ERR(var))
>> return PTR_ERR(var);
>>
>>
> I'm saying to leave the code alone.
Do I need to try another interpretation out for your feedback?
> If it goes:
>
> var = foo_that_returns_ptr_err()
> if (IS_ERR(var))
> return PTR_ERR(var);
>
> p->bar = var;
>
> or whatever, simply keep it that way!
Do you
>> Now I find still that your data reorgansisation wish can not be resolved
>> in a simple way.
>
> I'm saying to leave the code alone.
It seems that there might be a misunderstanding between us.
> If it goes:
>
> var = foo_that_returns_ptr_err()
> if (IS_ERR(var))
>
From: SF Markus Elfring
Date: Thu, 18 Dec 2014 18:23:08 +0100
>>> Where should "the error pointers" be stored instead?
>>
>> A local variable, before you assign it into the datastructure.
>
> I have looked at the affected software infrastructure once more.
> Now I find still that your data reor
>> Where should "the error pointers" be stored instead?
>
> A local variable, before you assign it into the datastructure.
I have looked at the affected software infrastructure once more.
Now I find still that your data reorgansisation wish can not be resolved
in a simple way.
I imagine that you
> I'd like to honestly ask why you are being so difficult?
There are several factors which contribute to your perception of
difficulty here.
1. I try to extract from every feedback the information about the amount
of acceptance or rejection for a specific update suggestion.
A terse feedback (l
> We are in the merge window, tracking bugs added in latest dev cycle.
I am also curious on the software evolution about how many improvements will
arrive in the next Linux versions.
> Having to deal with patches like yours is adding pressure
> on the maintainer (and other developers) at the wro
From: SF Markus Elfring
Date: Fri, 12 Dec 2014 18:22:48 +0100
>>> Where should "the error pointers" be stored instead?
>> A local variable, before you assign it into the datastructure.
>
> Will it be acceptable for you that anyone (or even me) will introduce
> such a change with a seventh (and e
On Fri, 2014-12-12 at 18:22 +0100, SF Markus Elfring wrote:
> Will it be acceptable for you that anyone (or even me) will introduce
> such a change with a seventh (and eventually eighth) update step here?
> Do you want any other sequence for source code preparation of
> the requested software impr
> I hope that a bit more constructive suggestions will be contributed by
> involved
> software developers around the affected source code. Now it seems
> that a small code clean-up becomes a more challenging development task.
This is often the case. Doing something half way is not useful.
julia
>> Where should "the error pointers" be stored instead?
> A local variable, before you assign it into the datastructure.
Will it be acceptable for you that anyone (or even me) will introduce
such a change with a seventh (and eventually eighth) update step here?
Do you want any other sequence for s
From: SF Markus Elfring
Date: Fri, 12 Dec 2014 17:56:36 +0100
> Where should "the error pointers" be stored instead?
A local variable, before you assign it into the datastructure.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vge
> You are asking me to invest a lot of time for a very trivial
> set of changes.
I find the proposed six update steps also trivial so far.
> Why don't you just integrate the feedback you were given and
> resubmit your patch series, just like any other developer would?
I find the requested rede
You are asking me to invest a lot of time for a very trivial
set of changes.
Why don't you just integrate the feedback you were given and
resubmit your patch series, just like any other developer would?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
> I gave you very concrete feedback, I said exactly that I don't want
> error pointers left in data structure members.
I find that your critique affects the proposed update steps four to six,
doesn't it?
Are the other steps acceptable in principle?
> I cannot describe my requirements any more pr
From: SF Markus Elfring
Date: Fri, 12 Dec 2014 08:01:54 +0100
>> Generally speaking, it is advisable to not leave error pointers in data
>> structures, even if they are about to be free'd up in an error path anyways.
>>
>> Therefore I do not like some of the patches in this series.
>
> Can you g
> Generally speaking, it is advisable to not leave error pointers in data
> structures, even if they are about to be free'd up in an error path anyways.
>
> Therefore I do not like some of the patches in this series.
Can you give any more concrete feedback here?
Regards,
Markus
--
To unsubscribe
From: SF Markus Elfring
Date: Thu, 04 Dec 2014 23:03:30 +0100
> From: Markus Elfring
> Date: Thu, 4 Dec 2014 22:50:28 +0100
>
> Further update suggestions were taken into account before and after a patch
> was applied from static source code analysis.
Generally speaking, it is advisable to not
From: Markus Elfring
Date: Thu, 4 Dec 2014 22:50:28 +0100
Further update suggestions were taken into account before and after a patch
was applied from static source code analysis.
Markus Elfring (6):
Replacement of a printk() call by pr_warn() in mppe_rekey()
Fix indentation
Deletion of un
21 matches
Mail list logo
