> If you can benchmark the code and the new code is faster then, yes, this
> patch is good and we will apply it.
I guess that I do not have enough resources myself to measure different run time
effects in a S390 environment.
> If you have no benchmarks then do not send the patch.
Are other soft
On Mon, 3 Nov 2014, Derek M Jones wrote:
> Dan
>
> > The truth is I think that all these patches are bad and they make the
> > code harder to read.
>
> I disagree, I think the code requires less effort to read without the
> if test.
>
> A developer reading the code will wonder why kfree does not h
Dan
The truth is I think that all these patches are bad and they make the
code harder to read.
I disagree, I think the code requires less effort to read without the
if test.
A developer reading the code will wonder why kfree does not handle the
case when its argument is NULL. This takes effo
On Mon, Nov 03, 2014 at 05:50:48PM +0100, SF Markus Elfring wrote:
> > After your patch then it will print warning messages.
>
> To which messages do you refer to?
>
Open your eyeballs up and read the code.
>
> > The truth is I think that all these patches are bad and they make the
> > code ha
> > After your patch then it will print warning messages.
> > After: You have to remember that rtw_free_netdev() accepts NULL
> > pointers but free_netdev() does not accept NULL pointers.
>
> Are any improvements needed for the corresponding documentation to make it
> better accessible besid
> After your patch then it will print warning messages.
To which messages do you refer to?
> The truth is I think that all these patches are bad and they make the
> code harder to read.
>
> Before: The code is clear and there is no NULL dereference.
Where do you stumble on a null pointer acce
On Mon, Nov 03, 2014 at 05:10:35PM +0100, SF Markus Elfring wrote:
> > I agree with your proposed debug_unregister() changes, but not with your
> > kfree_fsm() change.
>
> Why do you want to keep an additional null pointer check before the call
> of the kfree_fsm() function within the implementati
On Mon, Nov 03, 2014 at 04:55:12PM +0100, SF Markus Elfring wrote:
> > This one is buggy.
>
> I am still interested to clarify this opinion a bit more.
>
After your patch then it will print warning messages.
The truth is I think that all these patches are bad and they make the
code harder to re
> This one is buggy.
I am still interested to clarify this opinion a bit more.
> I'm sorry, but please stop sending these.
I am going to improve more implementation details in affected source files.
> But for this one:
> 1) I don't know what the functions do so I have to look at the code.
I
> I agree with your proposed debug_unregister() changes, but not with your
> kfree_fsm() change.
Why do you want to keep an additional null pointer check before the call
of the kfree_fsm() function within the implementation of the
netiucv_free_netdevice() function?
Regards,
Markus
___
10 matches
Mail list logo
