> NULL check before kfree is unnecessary so remove it.
I hope that you would like to take another update suggestion into account
(besides a typo correction for your commit message).
https://lore.kernel.org/patchwork/patch/1220189/
https://lore.kernel.org/linux-scsi/[email protected]/
Do you find a previous update suggestion like “SCSI-aic7...: Delete unnecessary
checks before the function call "kfree"” also interesting?
https://lore.kernel.org/linux-scsi/[email protected]/
https://lore.kernel.org/patchwork/patch/540593/
https://lkml.org/lkml/2015/2/5/650
Regards,
Markus
Sorry about nnnnoise, please just ignore it.
On Mon, Apr 6, 2020 at 4:02 AM Markus Elfring <[email protected]> wrote:
>
> > NULL check before kfree is unnecessary so remove it.
>
> I hope that you would like to take another update suggestion into account
> (besides a typo correction for your commit message).
> https://lore.kernel.org/patchwork/patch/1220189/
> https://lore.kernel.org/linux-scsi/[email protected]/
>
> Do you find a previous update suggestion like “SCSI-aic7...: Delete unnecessary
> checks before the function call "kfree"” also interesting?
> https://lore.kernel.org/linux-scsi/[email protected]/
> https://lore.kernel.org/patchwork/patch/540593/
> https://lkml.org/lkml/2015/2/5/650
>
> Regards,
> Markus
Markus,
On Sun, Apr 05, 2020 at 10:02:47PM +0200, Markus Elfring wrote:
> > NULL check before kfree is unnecessary so remove it.
>
> I hope that you would like to take another update suggestion into account
> (besides a typo correction for your commit message).
> https://lore.kernel.org/patchwork/patch/1220189/
> https://lore.kernel.org/linux-scsi/[email protected]/
I'm not sure I understand the relevance. Are you saying I should
reference this other patch?
>
> Do you find a previous update suggestion like “SCSI-aic7...: Delete unnecessary
> checks before the function call "kfree"” also interesting?
> https://lore.kernel.org/linux-scsi/[email protected]/
> https://lore.kernel.org/patchwork/patch/540593/
> https://lkml.org/lkml/2015/2/5/650
>
Thanks for the reference. I'll mention it in the commit if I do a v2.
Best,
Alex
> Regards,
> Markus
>> I hope that you would like to take another update suggestion into account
>> (besides a typo correction for your commit message).
>> https://lore.kernel.org/patchwork/patch/1220189/
>> https://lore.kernel.org/linux-scsi/[email protected]/
>
> I'm not sure I understand the relevance.
I pointed your patch out for another contributor.
> Are you saying I should reference this other patch?
I suggest to take another look at the development history for presented
patches according to a known source code search pattern.
> Thanks for the reference. I'll mention it in the commit if I do a v2.
I am curious under which circumstances the affected source files
will actually be improved in ways which were suggested a few times.
Regards,
Markus
On Tue, Apr 07, 2020 at 06:32:19PM +0200, Markus Elfring wrote:
> >> I hope that you would like to take another update suggestion into account
> >> (besides a typo correction for your commit message).
> >> https://lore.kernel.org/patchwork/patch/1220189/
> >> https://lore.kernel.org/linux-scsi/[email protected]/
> >
> > I'm not sure I understand the relevance.
>
> I pointed your patch out for another contributor.
>
>
> > Are you saying I should reference this other patch?
>
> I suggest to take another look at the development history for presented
> patches according to a known source code search pattern.
Ok, cool. How should I go about that?
The thing is that this seems like an obvious improvement (albeit not a
terribly critical one). It reduces SLoC and removes an unnecessary
check. AFAICS the patch you mention wasn't rejected on technical
grounds, but simply wasn't picked up. If there is a reason why this
change isn't warranted then I'd like to know why so I can send better
patches in future :-)
>
>
> > Thanks for the reference. I'll mention it in the commit if I do a v2.
>
> I am curious under which circumstances the affected source files
> will actually be improved in ways which were suggested a few times.
>
> Regards,
> Markus
> The thing is that this seems like an obvious improvement
Such a view can be promising.
> (albeit not a terribly critical one).
The prioritisation influences change integration considerably.
> It reduces SLoC and removes an unnecessary check.
I hope that such goals will be reconsidered also for this software module.
> AFAICS the patch you mention wasn't rejected on technical grounds,
> but simply wasn't picked up.
The usual factors were involved for free software development.
> If there is a reason why this change isn't warranted
> then I'd like to know why so I can send better patches in future :-)
I hope that also your change interests can increase chances for
software evolution in desired directions.
With which delays will specific improvements be achieved?
Regards,
Markus