Hi Markus,
this discussion went far beyond the original posted patch for vxcan.c
I would suggest you post your idea of the simplified error handling flow
in vxcan.c just on linux-can ML (which is the right mailing list for CAN
related stuff).
Thanks,
Oliver
On 10/28/2017 10:13 PM, SF Markus
>> Are you interested in related adjustments for a bigger code base?
>
> No. Definitely not.
You might have noticed that I am proposing similar changes already
for other software modules. ;-)
> If you aim for the the deletion of “ < 0” for all rtnl_configure_link() users
> you would need to d
On 10/28/2017 09:18 PM, SF Markus Elfring wrote:
If you want to change the semantic of the result check
I am curious if another source code reduction (by the deletion of “ < 0”)
will become acceptable at similar places.
Source code reduction is not the main target.
If you can simplify code w
> If you want to change the semantic of the result check
I am curious if another source code reduction (by the deletion of “ < 0”)
will become acceptable at similar places.
> - this has to done consistently at all rtnl_configure_link() caller sites.
Are there any more functions to consider?
>
On 10/28/2017 08:33 PM, SF Markus Elfring wrote:
So if you would like to change the if-statement:
It will need a small adjustment for the shown transformation.
I was also unsure if the proposal will work in a single update step.
1. Send a patch for vxcan.c to improve the error handling flow
> So if you would like to change the if-statement:
It will need a small adjustment for the shown transformation.
I was also unsure if the proposal will work in a single update step.
> 1. Send a patch for vxcan.c to improve the error handling flow
I am going to send a second approach for this u
