* [PATCH 1/2] net: netrom: mark expected switch fall-throughs
@ 2017-10-19 17:21 Gustavo A. R. Silva
2017-10-19 17:27 ` [PATCH 2/2] net: netrom: refactor code in nr_add_node Gustavo A. R. Silva
0 siblings, 1 reply; 24+ messages in thread
From: Gustavo A. R. Silva @ 2017-10-19 17:21 UTC (permalink / raw)
To: Ralf Baechle, David S. Miller
Cc: linux-hams, netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
---
This code was tested by compilation only (GCC 7.2.0 was used).
Please, verify if the actual intention of the code is to fall through.
net/netrom/nr_route.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index 0c59354..fc9cadc 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -279,6 +279,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
nr_node->routes[1] = nr_node->routes[2];
nr_node->routes[2] = nr_route;
}
+ /* fall through */
case 2:
if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
switch (nr_node->which) {
@@ -384,6 +385,7 @@ static int nr_del_node(ax25_address *callsign, ax25_address *neighbour, struct n
switch (i) {
case 0:
nr_node->routes[0] = nr_node->routes[1];
+ /* fall through */
case 1:
nr_node->routes[1] = nr_node->routes[2];
case 2:
@@ -506,7 +508,7 @@ static int nr_dec_obs(void)
switch (i) {
case 0:
s->routes[0] = s->routes[1];
- /* Fallthrough */
+ /* fall through */
case 1:
s->routes[1] = s->routes[2];
case 2:
@@ -553,6 +555,7 @@ void nr_rt_device_down(struct net_device *dev)
switch (i) {
case 0:
t->routes[0] = t->routes[1];
+ /* fall through */
case 1:
t->routes[1] = t->routes[2];
case 2:
--
2.7.4
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH 2/2] net: netrom: refactor code in nr_add_node
2017-10-19 17:21 [PATCH 1/2] net: netrom: mark expected switch fall-throughs Gustavo A. R. Silva
@ 2017-10-19 17:27 ` Gustavo A. R. Silva
2017-10-20 8:57 ` walter harms
0 siblings, 1 reply; 24+ messages in thread
From: Gustavo A. R. Silva @ 2017-10-19 17:27 UTC (permalink / raw)
To: Ralf Baechle, David S. Miller
Cc: linux-hams, netdev, linux-kernel, Gustavo A. R. Silva
Code refactoring in order to make the code easier to read and maintain.
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
---
This code was tested by compilation only (GCC 7.2.0 was used).
net/netrom/nr_route.c | 63 ++++++++++++++++-----------------------------------
1 file changed, 20 insertions(+), 43 deletions(-)
diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index fc9cadc..1e5165f 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -80,6 +80,23 @@ static struct nr_neigh *nr_neigh_get_dev(ax25_address *callsign,
static void nr_remove_neigh(struct nr_neigh *);
+/* re-sort the routes in quality order. */
+static inline void re_sort_routes(struct nr_node *nr_node, int ix_x, int ix_y)
+{
+ struct nr_route nr_route;
+
+ if (nr_node->routes[ix_y].quality > nr_node->routes[ix_x].quality) {
+ if (nr_node->which == ix_x)
+ nr_node->which = ix_y;
+ else if (nr_node->which == ix_y)
+ nr_node->which = ix_x;
+
+ nr_route = nr_node->routes[ix_x];
+ nr_node->routes[ix_x] = nr_node->routes[ix_y];
+ nr_node->routes[ix_y] = nr_route;
+ }
+}
+
/*
* Add a new route to a node, and in the process add the node and the
* neighbour if it is new.
@@ -90,7 +107,6 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
{
struct nr_node *nr_node;
struct nr_neigh *nr_neigh;
- struct nr_route nr_route;
int i, found;
struct net_device *odev;
@@ -251,50 +267,11 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
/* Now re-sort the routes in quality order */
switch (nr_node->count) {
case 3:
- if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
- switch (nr_node->which) {
- case 0:
- nr_node->which = 1;
- break;
- case 1:
- nr_node->which = 0;
- break;
- }
- nr_route = nr_node->routes[0];
- nr_node->routes[0] = nr_node->routes[1];
- nr_node->routes[1] = nr_route;
- }
- if (nr_node->routes[2].quality > nr_node->routes[1].quality) {
- switch (nr_node->which) {
- case 1: nr_node->which = 2;
- break;
-
- case 2: nr_node->which = 1;
- break;
-
- default:
- break;
- }
- nr_route = nr_node->routes[1];
- nr_node->routes[1] = nr_node->routes[2];
- nr_node->routes[2] = nr_route;
- }
+ re_sort_routes(nr_node, 0, 1);
+ re_sort_routes(nr_node, 1, 2);
/* fall through */
case 2:
- if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
- switch (nr_node->which) {
- case 0: nr_node->which = 1;
- break;
-
- case 1: nr_node->which = 0;
- break;
-
- default: break;
- }
- nr_route = nr_node->routes[0];
- nr_node->routes[0] = nr_node->routes[1];
- nr_node->routes[1] = nr_route;
- }
+ re_sort_routes(nr_node, 0, 1);
case 1:
break;
}
--
2.7.4
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH 2/2] net: netrom: refactor code in nr_add_node
2017-10-19 17:27 ` [PATCH 2/2] net: netrom: refactor code in nr_add_node Gustavo A. R. Silva
@ 2017-10-20 8:57 ` walter harms
0 siblings, 0 replies; 24+ messages in thread
From: walter harms @ 2017-10-20 8:57 UTC (permalink / raw)
To: Gustavo A. R. Silva; +Cc: Ralf Baechle, David S. Miller, linux-hams, netdev
Am 19.10.2017 19:27, schrieb Gustavo A. R. Silva:
> Code refactoring in order to make the code easier to read and maintain.
>
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
> ---
> This code was tested by compilation only (GCC 7.2.0 was used).
>
> net/netrom/nr_route.c | 63 ++++++++++++++++-----------------------------------
> 1 file changed, 20 insertions(+), 43 deletions(-)
>
> diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
> index fc9cadc..1e5165f 100644
> --- a/net/netrom/nr_route.c
> +++ b/net/netrom/nr_route.c
> @@ -80,6 +80,23 @@ static struct nr_neigh *nr_neigh_get_dev(ax25_address *callsign,
>
> static void nr_remove_neigh(struct nr_neigh *);
>
> +/* re-sort the routes in quality order. */
> +static inline void re_sort_routes(struct nr_node *nr_node, int ix_x, int ix_y)
> +{
> + struct nr_route nr_route;
> +
> + if (nr_node->routes[ix_y].quality > nr_node->routes[ix_x].quality) {
> + if (nr_node->which == ix_x)
> + nr_node->which = ix_y;
> + else if (nr_node->which == ix_y)
> + nr_node->which = ix_x;
> +
> + nr_route = nr_node->routes[ix_x];
> + nr_node->routes[ix_x] = nr_node->routes[ix_y];
> + nr_node->routes[ix_y] = nr_route;
> + }
> +}
> +
Good idea, a bit of nit picking ..
does ix_ has a special meaning ? otherwise x,y would be sufficient.
>From the code below i can see: y=x+1 Perhaps that can be used.
kernel.h has a swap() macro. so you can swap(nr_node->routes[x],nr_node->routes[y]);
hope that helps,
re,
wh
> /*
> * Add a new route to a node, and in the process add the node and the
> * neighbour if it is new.
> @@ -90,7 +107,6 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
> {
> struct nr_node *nr_node;
> struct nr_neigh *nr_neigh;
> - struct nr_route nr_route;
> int i, found;
> struct net_device *odev;
>
> @@ -251,50 +267,11 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
> /* Now re-sort the routes in quality order */
> switch (nr_node->count) {
> case 3:
> - if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
> - switch (nr_node->which) {
> - case 0:
> - nr_node->which = 1;
> - break;
> - case 1:
> - nr_node->which = 0;
> - break;
> - }
> - nr_route = nr_node->routes[0];
> - nr_node->routes[0] = nr_node->routes[1];
> - nr_node->routes[1] = nr_route;
> - }
> - if (nr_node->routes[2].quality > nr_node->routes[1].quality) {
> - switch (nr_node->which) {
> - case 1: nr_node->which = 2;
> - break;
> -
> - case 2: nr_node->which = 1;
> - break;
> -
> - default:
> - break;
> - }
> - nr_route = nr_node->routes[1];
> - nr_node->routes[1] = nr_node->routes[2];
> - nr_node->routes[2] = nr_route;
> - }
> + re_sort_routes(nr_node, 0, 1);
> + re_sort_routes(nr_node, 1, 2);
> /* fall through */
> case 2:
> - if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
> - switch (nr_node->which) {
> - case 0: nr_node->which = 1;
> - break;
> -
> - case 1: nr_node->which = 0;
> - break;
> -
> - default: break;
> - }
> - nr_route = nr_node->routes[0];
> - nr_node->routes[0] = nr_node->routes[1];
> - nr_node->routes[1] = nr_route;
> - }
> + re_sort_routes(nr_node, 0, 1);
> case 1:
> break;
> }
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/2] net: netrom: refactor code in nr_add_node
@ 2017-10-20 8:57 ` walter harms
0 siblings, 0 replies; 24+ messages in thread
From: walter harms @ 2017-10-20 8:57 UTC (permalink / raw)
To: Gustavo A. R. Silva; +Cc: Ralf Baechle, David S. Miller, linux-hams, netdev
Am 19.10.2017 19:27, schrieb Gustavo A. R. Silva:
> Code refactoring in order to make the code easier to read and maintain.
>
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
> ---
> This code was tested by compilation only (GCC 7.2.0 was used).
>
> net/netrom/nr_route.c | 63 ++++++++++++++++-----------------------------------
> 1 file changed, 20 insertions(+), 43 deletions(-)
>
> diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
> index fc9cadc..1e5165f 100644
> --- a/net/netrom/nr_route.c
> +++ b/net/netrom/nr_route.c
> @@ -80,6 +80,23 @@ static struct nr_neigh *nr_neigh_get_dev(ax25_address *callsign,
>
> static void nr_remove_neigh(struct nr_neigh *);
>
> +/* re-sort the routes in quality order. */
> +static inline void re_sort_routes(struct nr_node *nr_node, int ix_x, int ix_y)
> +{
> + struct nr_route nr_route;
> +
> + if (nr_node->routes[ix_y].quality > nr_node->routes[ix_x].quality) {
> + if (nr_node->which == ix_x)
> + nr_node->which = ix_y;
> + else if (nr_node->which == ix_y)
> + nr_node->which = ix_x;
> +
> + nr_route = nr_node->routes[ix_x];
> + nr_node->routes[ix_x] = nr_node->routes[ix_y];
> + nr_node->routes[ix_y] = nr_route;
> + }
> +}
> +
Good idea, a bit of nit picking ..
does ix_ has a special meaning ? otherwise x,y would be sufficient.
From the code below i can see: y=x+1 Perhaps that can be used.
kernel.h has a swap() macro. so you can swap(nr_node->routes[x],nr_node->routes[y]);
hope that helps,
re,
wh
> /*
> * Add a new route to a node, and in the process add the node and the
> * neighbour if it is new.
> @@ -90,7 +107,6 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
> {
> struct nr_node *nr_node;
> struct nr_neigh *nr_neigh;
> - struct nr_route nr_route;
> int i, found;
> struct net_device *odev;
>
> @@ -251,50 +267,11 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
> /* Now re-sort the routes in quality order */
> switch (nr_node->count) {
> case 3:
> - if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
> - switch (nr_node->which) {
> - case 0:
> - nr_node->which = 1;
> - break;
> - case 1:
> - nr_node->which = 0;
> - break;
> - }
> - nr_route = nr_node->routes[0];
> - nr_node->routes[0] = nr_node->routes[1];
> - nr_node->routes[1] = nr_route;
> - }
> - if (nr_node->routes[2].quality > nr_node->routes[1].quality) {
> - switch (nr_node->which) {
> - case 1: nr_node->which = 2;
> - break;
> -
> - case 2: nr_node->which = 1;
> - break;
> -
> - default:
> - break;
> - }
> - nr_route = nr_node->routes[1];
> - nr_node->routes[1] = nr_node->routes[2];
> - nr_node->routes[2] = nr_route;
> - }
> + re_sort_routes(nr_node, 0, 1);
> + re_sort_routes(nr_node, 1, 2);
> /* fall through */
> case 2:
> - if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
> - switch (nr_node->which) {
> - case 0: nr_node->which = 1;
> - break;
> -
> - case 1: nr_node->which = 0;
> - break;
> -
> - default: break;
> - }
> - nr_route = nr_node->routes[0];
> - nr_node->routes[0] = nr_node->routes[1];
> - nr_node->routes[1] = nr_route;
> - }
> + re_sort_routes(nr_node, 0, 1);
> case 1:
> break;
> }
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/2] net: netrom: refactor code in nr_add_node
2017-10-20 8:57 ` walter harms
(?)
@ 2017-10-20 16:06 ` Gustavo A. R. Silva
2017-10-20 16:54 ` walter harms
-1 siblings, 1 reply; 24+ messages in thread
From: Gustavo A. R. Silva @ 2017-10-20 16:06 UTC (permalink / raw)
To: walter harms; +Cc: Ralf Baechle, David S. Miller, linux-hams, netdev
Hi Walter,
Quoting walter harms <wharms@bfs.de>:
> Am 19.10.2017 19:27, schrieb Gustavo A. R. Silva:
>> Code refactoring in order to make the code easier to read and maintain.
>>
>> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
>> ---
>> This code was tested by compilation only (GCC 7.2.0 was used).
>>
>> net/netrom/nr_route.c | 63
>> ++++++++++++++++-----------------------------------
>> 1 file changed, 20 insertions(+), 43 deletions(-)
>>
>> diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
>> index fc9cadc..1e5165f 100644
>> --- a/net/netrom/nr_route.c
>> +++ b/net/netrom/nr_route.c
>> @@ -80,6 +80,23 @@ static struct nr_neigh
>> *nr_neigh_get_dev(ax25_address *callsign,
>>
>> static void nr_remove_neigh(struct nr_neigh *);
>>
>> +/* re-sort the routes in quality order. */
>> +static inline void re_sort_routes(struct nr_node *nr_node, int
>> ix_x, int ix_y)
>> +{
>> + struct nr_route nr_route;
>> +
>> + if (nr_node->routes[ix_y].quality > nr_node->routes[ix_x].quality) {
>> + if (nr_node->which == ix_x)
>> + nr_node->which = ix_y;
>> + else if (nr_node->which == ix_y)
>> + nr_node->which = ix_x;
>> +
>> + nr_route = nr_node->routes[ix_x];
>> + nr_node->routes[ix_x] = nr_node->routes[ix_y];
>> + nr_node->routes[ix_y] = nr_route;
>> + }
>> +}
>> +
>
>
> Good idea, a bit of nit picking ..
> does ix_ has a special meaning ? otherwise x,y would be sufficient.
ix typical stands for index, but I think just x and y are fine too.
> From the code below i can see: y=x+1 Perhaps that can be used.
>
So are you proposing to use two arguments instead of three?
re_sort_routes(nr_node, 0);
> kernel.h has a swap() macro. so you can
> swap(nr_node->routes[x],nr_node->routes[y]);
>
Nice, I will use that macro.
> hope that helps,
Definitely. I appreciate your comments.
Thanks!
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/2] net: netrom: refactor code in nr_add_node
2017-10-20 16:06 ` Gustavo A. R. Silva
@ 2017-10-20 16:54 ` walter harms
2017-10-20 23:09 ` Kevin Dawson
2017-10-23 0:41 ` Gustavo A. R. Silva
0 siblings, 2 replies; 24+ messages in thread
From: walter harms @ 2017-10-20 16:54 UTC (permalink / raw)
To: Gustavo A. R. Silva; +Cc: Ralf Baechle, David S. Miller, linux-hams, netdev
Am 20.10.2017 18:06, schrieb Gustavo A. R. Silva:
> Hi Walter,
>
> Quoting walter harms <wharms@bfs.de>:
>
>> Am 19.10.2017 19:27, schrieb Gustavo A. R. Silva:
>>> Code refactoring in order to make the code easier to read and maintain.
>>>
>>> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
>>> ---
>>> This code was tested by compilation only (GCC 7.2.0 was used).
>>>
>>> net/netrom/nr_route.c | 63
>>> ++++++++++++++++-----------------------------------
>>> 1 file changed, 20 insertions(+), 43 deletions(-)
>>>
>>> diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
>>> index fc9cadc..1e5165f 100644
>>> --- a/net/netrom/nr_route.c
>>> +++ b/net/netrom/nr_route.c
>>> @@ -80,6 +80,23 @@ static struct nr_neigh
>>> *nr_neigh_get_dev(ax25_address *callsign,
>>>
>>> static void nr_remove_neigh(struct nr_neigh *);
>>>
>>> +/* re-sort the routes in quality order. */
>>> +static inline void re_sort_routes(struct nr_node *nr_node, int ix_x,
>>> int ix_y)
>>> +{
>>> + struct nr_route nr_route;
>>> +
>>> + if (nr_node->routes[ix_y].quality >
>>> nr_node->routes[ix_x].quality) {
>>> + if (nr_node->which == ix_x)
>>> + nr_node->which = ix_y;
>>> + else if (nr_node->which == ix_y)
>>> + nr_node->which = ix_x;
>>> +
>>> + nr_route = nr_node->routes[ix_x];
>>> + nr_node->routes[ix_x] = nr_node->routes[ix_y];
>>> + nr_node->routes[ix_y] = nr_route;
>>> + }
>>> +}
>>> +
>>
>>
>> Good idea, a bit of nit picking ..
>> does ix_ has a special meaning ? otherwise x,y would be sufficient.
>
> ix typical stands for index, but I think just x and y are fine too.
>
>> From the code below i can see: y=x+1 Perhaps that can be used.
>>
>
> So are you proposing to use two arguments instead of three?
>
> re_sort_routes(nr_node, 0);
>
I am not sure, i would wait a bit and see if what improves readability.
as Kevin Dawson pointed out: this is a sort here.
Maybe there a nice way to do something like that (i do not know):
case 3:
re_sort_routes(nr_node, 1,2)
case 2:
re_sort_routes(nr_node, 0,1)
case 1:
break;
The question is: Is the sorted list needed or simply the maximum ?
NTL is a good thing to chop down the function in smaller digestible
peaces.
re,
wh
>
>> kernel.h has a swap() macro. so you can
>> swap(nr_node->routes[x],nr_node->routes[y]);
>>
>
> Nice, I will use that macro.
>
>> hope that helps,
>
> Definitely. I appreciate your comments.
>
> Thanks!
> --
> Gustavo A. R. Silva
>
>
>
>
>
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/2] net: netrom: refactor code in nr_add_node
2017-10-20 16:54 ` walter harms
@ 2017-10-20 23:09 ` Kevin Dawson
2017-10-23 0:41 ` Gustavo A. R. Silva
1 sibling, 0 replies; 24+ messages in thread
From: Kevin Dawson @ 2017-10-20 23:09 UTC (permalink / raw)
To: walter harms
Cc: Gustavo A. R. Silva, Ralf Baechle, David S. Miller, linux-hams, netdev
Hello all.
My original response just went to Gustavo and Walter because I'm not much of a kernel hacker these days; it was mainly observations that may or may not have been helpful and I'm not a regular list contributor. Looks like I shouldn't have been so shy!
On Fri, Oct 20, 2017 at 06:54:05PM +0200, walter harms wrote:
>
> ...
>
> >> From the code below i can see: y=x+1 Perhaps that can be used.
> >
> > So are you proposing to use two arguments instead of three?
> >
> > re_sort_routes(nr_node, 0);
>
> I am not sure, i would wait a bit and see if what improves readability.
> as Kevin Dawson pointed out: this is a sort here.
> Maybe there a nice way to do something like that (i do not know):
>
> case 3:
> re_sort_routes(nr_node, 1,2)
> case 2:
> re_sort_routes(nr_node, 0,1)
> case 1:
> break;
Nearly - you left out one of the calls to re_sort_routes. I include my original mail here, as it explains it better:
> Hi Walter and Gustavo.
>
> I've just left this response for the two of you, as it's a long time since I've been fiddling in the kernel and I don't know much of the current ideology regarding how people want their coding done.
>
> I also only have a passing knowledge of NetRom, but I do recall some of the principles like routes and their quality.
>
> On Fri, Oct 20, 2017 at 10:57:10AM +0200, walter harms wrote:
> >
> > Am 19.10.2017 19:27, schrieb Gustavo A. R. Silva:
> > > Code refactoring in order to make the code easier to read and maintain.
>
> ...
>
> [ Gustavo ]
> > > +/* re-sort the routes in quality order. */
> > > +static inline void re_sort_routes(struct nr_node *nr_node, int ix_x, int ix_y)
>
> I'm curious as to why re_sort_routes() is declared inline. Its use below hardly gains any efficiency from saving function calls; as well, it's extra code space taken.
>
> > > + if (nr_node->which == ix_x)
> > > + nr_node->which = ix_y;
> > > + else if (nr_node->which == ix_y)
> > > + nr_node->which = ix_x;
>
> I suspect this can be simplified too, but I don't know what the possible values for ->which might be in any particular route case.
>
> ...
>
> [ Walter ]
> > From the code below i can see: y=x+1 Perhaps that can be used.
> > ...
> > > /* Now re-sort the routes in quality order */
> > > switch (nr_node->count) {
> > > case 3:
> > > re_sort_routes(nr_node, 0, 1);
> > > re_sort_routes(nr_node, 1, 2);
> > > /* fall through */
> > > case 2:
> > > re_sort_routes(nr_node, 0, 1);
> > > case 1:
> > > break;
> > > }
>
> Yes, it can and it makes sense to do so. The algorithm is an unrolled bubblesort for up to 3 routes. If 3 is as far as it will ever go (and given that's all the original function allowed for), it's not unjustified in leaving it that way. Anything more and I'd be suggesting it be made a loop.
>
> > kernel.h has a swap() macro. so you can swap(nr_node->routes[x],nr_node->routes[y]);
>
> I presume the swap() macro handles arbitrary types - structs and not just ints. If the aim is to improve readability of the code, it helps.
>
> I hope I'm not completely out of line in suggesting this. As I say, it's been quite a while since I've dabbled in the kernel (although I did start back in the 1970s on Unix...).
>
> Thanks,
> Kevin
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 2/2] net: netrom: refactor code in nr_add_node
2017-10-20 16:54 ` walter harms
2017-10-20 23:09 ` Kevin Dawson
@ 2017-10-23 0:41 ` Gustavo A. R. Silva
2017-10-23 1:08 ` [PATCH v2 " Gustavo A. R. Silva
1 sibling, 1 reply; 24+ messages in thread
From: Gustavo A. R. Silva @ 2017-10-23 0:41 UTC (permalink / raw)
To: walter harms; +Cc: Ralf Baechle, David S. Miller, linux-hams, netdev
Quoting walter harms <wharms@bfs.de>:
> Am 20.10.2017 18:06, schrieb Gustavo A. R. Silva:
>> Hi Walter,
>>
>> Quoting walter harms <wharms@bfs.de>:
>>
>>> Am 19.10.2017 19:27, schrieb Gustavo A. R. Silva:
>>>> Code refactoring in order to make the code easier to read and maintain.
>>>>
>>>> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
>>>> ---
>>>> This code was tested by compilation only (GCC 7.2.0 was used).
>>>>
>>>> net/netrom/nr_route.c | 63
>>>> ++++++++++++++++-----------------------------------
>>>> 1 file changed, 20 insertions(+), 43 deletions(-)
>>>>
>>>> diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
>>>> index fc9cadc..1e5165f 100644
>>>> --- a/net/netrom/nr_route.c
>>>> +++ b/net/netrom/nr_route.c
>>>> @@ -80,6 +80,23 @@ static struct nr_neigh
>>>> *nr_neigh_get_dev(ax25_address *callsign,
>>>>
>>>> static void nr_remove_neigh(struct nr_neigh *);
>>>>
>>>> +/* re-sort the routes in quality order. */
>>>> +static inline void re_sort_routes(struct nr_node *nr_node, int ix_x,
>>>> int ix_y)
>>>> +{
>>>> + struct nr_route nr_route;
>>>> +
>>>> + if (nr_node->routes[ix_y].quality >
>>>> nr_node->routes[ix_x].quality) {
>>>> + if (nr_node->which == ix_x)
>>>> + nr_node->which = ix_y;
>>>> + else if (nr_node->which == ix_y)
>>>> + nr_node->which = ix_x;
>>>> +
>>>> + nr_route = nr_node->routes[ix_x];
>>>> + nr_node->routes[ix_x] = nr_node->routes[ix_y];
>>>> + nr_node->routes[ix_y] = nr_route;
>>>> + }
>>>> +}
>>>> +
>>>
>>>
>>> Good idea, a bit of nit picking ..
>>> does ix_ has a special meaning ? otherwise x,y would be sufficient.
>>
>> ix typical stands for index, but I think just x and y are fine too.
>>
>>> From the code below i can see: y=x+1 Perhaps that can be used.
>>>
>>
>> So are you proposing to use two arguments instead of three?
>>
>> re_sort_routes(nr_node, 0);
>>
>
> I am not sure, i would wait a bit and see if what improves readability.
> as Kevin Dawson pointed out: this is a sort here.
> Maybe there a nice way to do something like that (i do not know):
>
> case 3:
> re_sort_routes(nr_node, 1,2)
> case 2:
> re_sort_routes(nr_node, 0,1)
> case 1:
> break;
>
> The question is: Is the sorted list needed or simply the maximum ?
>
> NTL is a good thing to chop down the function in smaller digestible
> peaces.
>
I'll use the swap macro as you suggested and leave the rest of this
patch as is for now.
Dawson:
Thanks for pointing out the thing about the inline keyword. I'll remove it.
Thanks
--
Gustavo A. R. Silva
> re,
> wh
>
>>
>>> kernel.h has a swap() macro. so you can
>>> swap(nr_node->routes[x],nr_node->routes[y]);
>>>
>>
>> Nice, I will use that macro.
>>
>>> hope that helps,
>>
>> Definitely. I appreciate your comments.
>>
>
>
>
>
>> Thanks!
>> --
>> Gustavo A. R. Silva
>>
>>
>>
>>
>>
>>
>>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v2 2/2] net: netrom: refactor code in nr_add_node
2017-10-23 0:41 ` Gustavo A. R. Silva
@ 2017-10-23 1:08 ` Gustavo A. R. Silva
2017-10-23 1:18 ` David Miller
2017-10-23 16:19 ` Fwd: [PATCH v2 2/2] net: netrom: refactor code in nr_add_node David Ranch
0 siblings, 2 replies; 24+ messages in thread
From: Gustavo A. R. Silva @ 2017-10-23 1:08 UTC (permalink / raw)
To: Ralf Baechle, David S. Miller, walter harms
Cc: linux-hams, netdev, linux-kernel, Gustavo A. R. Silva
Code refactoring in order to make it easier to read and maintain.
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
---
This code was tested by compilation only.
Changes in v2:
Make use of the swap macro and remove inline keyword.
net/netrom/nr_route.c | 59 ++++++++++++++-------------------------------------
1 file changed, 16 insertions(+), 43 deletions(-)
diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index fc9cadc..505e142 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -80,6 +80,19 @@ static struct nr_neigh *nr_neigh_get_dev(ax25_address *callsign,
static void nr_remove_neigh(struct nr_neigh *);
+/* re-sort the routes in quality order. */
+static void re_sort_routes(struct nr_node *nr_node, int x, int y)
+{
+ if (nr_node->routes[y].quality > nr_node->routes[x].quality) {
+ if (nr_node->which == x)
+ nr_node->which = y;
+ else if (nr_node->which == y)
+ nr_node->which = x;
+
+ swap(nr_node->routes[x], nr_node->routes[y]);
+ }
+}
+
/*
* Add a new route to a node, and in the process add the node and the
* neighbour if it is new.
@@ -90,7 +103,6 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
{
struct nr_node *nr_node;
struct nr_neigh *nr_neigh;
- struct nr_route nr_route;
int i, found;
struct net_device *odev;
@@ -251,50 +263,11 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
/* Now re-sort the routes in quality order */
switch (nr_node->count) {
case 3:
- if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
- switch (nr_node->which) {
- case 0:
- nr_node->which = 1;
- break;
- case 1:
- nr_node->which = 0;
- break;
- }
- nr_route = nr_node->routes[0];
- nr_node->routes[0] = nr_node->routes[1];
- nr_node->routes[1] = nr_route;
- }
- if (nr_node->routes[2].quality > nr_node->routes[1].quality) {
- switch (nr_node->which) {
- case 1: nr_node->which = 2;
- break;
-
- case 2: nr_node->which = 1;
- break;
-
- default:
- break;
- }
- nr_route = nr_node->routes[1];
- nr_node->routes[1] = nr_node->routes[2];
- nr_node->routes[2] = nr_route;
- }
+ re_sort_routes(nr_node, 0, 1);
+ re_sort_routes(nr_node, 1, 2);
/* fall through */
case 2:
- if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
- switch (nr_node->which) {
- case 0: nr_node->which = 1;
- break;
-
- case 1: nr_node->which = 0;
- break;
-
- default: break;
- }
- nr_route = nr_node->routes[0];
- nr_node->routes[0] = nr_node->routes[1];
- nr_node->routes[1] = nr_route;
- }
+ re_sort_routes(nr_node, 0, 1);
case 1:
break;
}
--
2.7.4
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH v2 2/2] net: netrom: refactor code in nr_add_node
2017-10-23 1:08 ` [PATCH v2 " Gustavo A. R. Silva
@ 2017-10-23 1:18 ` David Miller
2017-10-23 1:39 ` Gustavo A. R. Silva
2017-10-23 16:19 ` Fwd: [PATCH v2 2/2] net: netrom: refactor code in nr_add_node David Ranch
1 sibling, 1 reply; 24+ messages in thread
From: David Miller @ 2017-10-23 1:18 UTC (permalink / raw)
To: garsilva; +Cc: ralf, wharms, linux-hams, netdev, linux-kernel
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Sun, 22 Oct 2017 20:08:40 -0500
> Code refactoring in order to make it easier to read and maintain.
>
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Gustavo, always when reposting a new version of a patch that is part of
a series you must _always_ repost the entire patch series.
Also, a proper patch series must begine with a "[PATCH 0/2] ..."
header posting explaining at a high level what the patch series
is doing, how it is doing it, and why it is doing it that way.
Thank you.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 2/2] net: netrom: refactor code in nr_add_node
2017-10-23 1:18 ` David Miller
@ 2017-10-23 1:39 ` Gustavo A. R. Silva
2017-10-27 5:50 ` [PATCH v3 0/2] refactor code and mark expected switch fall-throughs Gustavo A. R. Silva
0 siblings, 1 reply; 24+ messages in thread
From: Gustavo A. R. Silva @ 2017-10-23 1:39 UTC (permalink / raw)
To: David Miller; +Cc: ralf, wharms, linux-hams, netdev, linux-kernel
Quoting David Miller <davem@davemloft.net>:
> From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
> Date: Sun, 22 Oct 2017 20:08:40 -0500
>
>> Code refactoring in order to make it easier to read and maintain.
>>
>> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
>
> Gustavo, always when reposting a new version of a patch that is part of
> a series you must _always_ repost the entire patch series.
>
OK. I got it.
> Also, a proper patch series must begine with a "[PATCH 0/2] ..."
> header posting explaining at a high level what the patch series
> is doing, how it is doing it, and why it is doing it that way.
>
Yeah, in this case I thought there was no need for this as both
patches are not actually related in terms of functionality. But now
that I'm writing this, maybe that is precisely the reason why I should
have posted such header...?
Thanks
--
Gustavo A. R. Silva
^ permalink raw reply [flat|nested] 24+ messages in thread
* Fwd: [PATCH v2 2/2] net: netrom: refactor code in nr_add_node
2017-10-23 1:08 ` [PATCH v2 " Gustavo A. R. Silva
2017-10-23 1:18 ` David Miller
@ 2017-10-23 16:19 ` David Ranch
1 sibling, 0 replies; 24+ messages in thread
From: David Ranch @ 2017-10-23 16:19 UTC (permalink / raw)
To: Linux Hams
Cc: Ralf Baechle, Thomas Osterried, Bernard, f6bvp, David S. Miller,
Gustavo A. R. Silva
Hey Everyone,
There are a LOT of patches coming in for the Linux AX.25 stack such as
this one below where people are proposing changes and they OPENLY state:
"This code was tested by compilation only"
That's NOT testing. We have seen over the last year or two, several
toxic commits have come into the kernel that have been extremely painful
to rollback and/or modify to remove the toxicity. I completely
appreciate people trying to keep the AX.25 stack cleaned up but it's
CRITICAL that we get some AX.25 regress suites running so people can
confirm that their proposed commits don't break anything before allowing
the commits. I've been trying to find out who to discuss this proposed
testing harness but I've been unable to get a name. Once I get a name,
I'm happy to help contribute some testing suites, etc. once I understand
the framework that this team(s) use.
--David
KI6ZHD
-------- Forwarded Message --------
Subject: [PATCH v2 2/2] net: netrom: refactor code in nr_add_node
Date: Sun, 22 Oct 2017 20:08:40 -0500
From: Gustavo A. R. Silva <garsilva@embeddedor.com>
To: Ralf Baechle <ralf@linux-mips.org>, David S. Miller
<davem@davemloft.net>, walter harms <wharms@bfs.de>
CC: linux-hams@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Gustavo A. R. Silva <garsilva@embeddedor.com>
Code refactoring in order to make it easier to read and maintain.
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
---
This code was tested by compilation only.
Changes in v2:
Make use of the swap macro and remove inline keyword.
net/netrom/nr_route.c | 59 ++++++++++++++-------------------------------------
1 file changed, 16 insertions(+), 43 deletions(-)
diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index fc9cadc..505e142 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -80,6 +80,19 @@ static struct nr_neigh *nr_neigh_get_dev(ax25_address *callsign,
static void nr_remove_neigh(struct nr_neigh *);
+/* re-sort the routes in quality order. */
+static void re_sort_routes(struct nr_node *nr_node, int x, int y)
+{
+ if (nr_node->routes[y].quality > nr_node->routes[x].quality) {
+ if (nr_node->which == x)
+ nr_node->which = y;
+ else if (nr_node->which == y)
+ nr_node->which = x;
+
+ swap(nr_node->routes[x], nr_node->routes[y]);
+ }
+}
+
/*
* Add a new route to a node, and in the process add the node and the
* neighbour if it is new.
@@ -90,7 +103,6 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
{
struct nr_node *nr_node;
struct nr_neigh *nr_neigh;
- struct nr_route nr_route;
int i, found;
struct net_device *odev;
@@ -251,50 +263,11 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
/* Now re-sort the routes in quality order */
switch (nr_node->count) {
case 3:
- if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
- switch (nr_node->which) {
- case 0:
- nr_node->which = 1;
- break;
- case 1:
- nr_node->which = 0;
- break;
- }
- nr_route = nr_node->routes[0];
- nr_node->routes[0] = nr_node->routes[1];
- nr_node->routes[1] = nr_route;
- }
- if (nr_node->routes[2].quality > nr_node->routes[1].quality) {
- switch (nr_node->which) {
- case 1: nr_node->which = 2;
- break;
-
- case 2: nr_node->which = 1;
- break;
-
- default:
- break;
- }
- nr_route = nr_node->routes[1];
- nr_node->routes[1] = nr_node->routes[2];
- nr_node->routes[2] = nr_route;
- }
+ re_sort_routes(nr_node, 0, 1);
+ re_sort_routes(nr_node, 1, 2);
/* fall through */
case 2:
- if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
- switch (nr_node->which) {
- case 0: nr_node->which = 1;
- break;
-
- case 1: nr_node->which = 0;
- break;
-
- default: break;
- }
- nr_route = nr_node->routes[0];
- nr_node->routes[0] = nr_node->routes[1];
- nr_node->routes[1] = nr_route;
- }
+ re_sort_routes(nr_node, 0, 1);
case 1:
break;
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH v3 0/2] refactor code and mark expected switch fall-throughs
2017-10-23 1:39 ` Gustavo A. R. Silva
@ 2017-10-27 5:50 ` Gustavo A. R. Silva
2017-10-27 5:51 ` [PATCH v3 1/2] net: netrom: nr_route: refactor code in nr_add_node Gustavo A. R. Silva
` (3 more replies)
0 siblings, 4 replies; 24+ messages in thread
From: Gustavo A. R. Silva @ 2017-10-27 5:50 UTC (permalink / raw)
To: linux-hams, netdev, linux-kernel
Cc: David S. Miller, Ralf Baechle, walter harms, Kevin Dawson,
Gustavo A. R. Silva
The aim of this patchset is firstly to refactor code in nr_route.c in order to make it
easier to read and maintain and, secondly, to mark some expected switch fall-throughs
in preparation to enabling -Wimplicit-fallthrough.
I have to mention that I did not implement any unit test.
If someone has any suggestions on how I could test this piece of code
it'd be greatly appreciated.
Thanks
Changes in v2:
- Make use of the swap macro and remove inline keyword as suggested by
Walter Harms and Kevin Dawson.
Changes in v3:
- Update subject for both patches.
- Add this cover letter as suggested by David Miller.
Gustavo A. R. Silva (2):
net: netrom: nr_route: refactor code in nr_add_node
net: netrom: nr_route: mark expected switch fall-throughs
net/netrom/nr_route.c | 62 ++++++++++++++++-----------------------------------
1 file changed, 19 insertions(+), 43 deletions(-)
--
2.7.4
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v3 1/2] net: netrom: nr_route: refactor code in nr_add_node
2017-10-27 5:50 ` [PATCH v3 0/2] refactor code and mark expected switch fall-throughs Gustavo A. R. Silva
@ 2017-10-27 5:51 ` Gustavo A. R. Silva
2017-10-27 5:51 ` [PATCH v3 2/2] net: netrom: nr_route: mark expected switch fall-throughs Gustavo A. R. Silva
` (2 subsequent siblings)
3 siblings, 0 replies; 24+ messages in thread
From: Gustavo A. R. Silva @ 2017-10-27 5:51 UTC (permalink / raw)
To: Ralf Baechle, David S. Miller
Cc: linux-hams, netdev, linux-kernel, Gustavo A. R. Silva
Code refactoring in order to make the code easier to read and maintain.
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
---
Changes in v2:
Make use of the swap macro and remove inline keyword.
Changes in v3:
Update subject.
net/netrom/nr_route.c | 59 ++++++++++++++-------------------------------------
1 file changed, 16 insertions(+), 43 deletions(-)
diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index 0c59354..fba4b4c 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -80,6 +80,19 @@ static struct nr_neigh *nr_neigh_get_dev(ax25_address *callsign,
static void nr_remove_neigh(struct nr_neigh *);
+/* re-sort the routes in quality order. */
+static void re_sort_routes(struct nr_node *nr_node, int x, int y)
+{
+ if (nr_node->routes[y].quality > nr_node->routes[x].quality) {
+ if (nr_node->which == x)
+ nr_node->which = y;
+ else if (nr_node->which == y)
+ nr_node->which = x;
+
+ swap(nr_node->routes[x], nr_node->routes[y]);
+ }
+}
+
/*
* Add a new route to a node, and in the process add the node and the
* neighbour if it is new.
@@ -90,7 +103,6 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
{
struct nr_node *nr_node;
struct nr_neigh *nr_neigh;
- struct nr_route nr_route;
int i, found;
struct net_device *odev;
@@ -251,49 +263,10 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
/* Now re-sort the routes in quality order */
switch (nr_node->count) {
case 3:
- if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
- switch (nr_node->which) {
- case 0:
- nr_node->which = 1;
- break;
- case 1:
- nr_node->which = 0;
- break;
- }
- nr_route = nr_node->routes[0];
- nr_node->routes[0] = nr_node->routes[1];
- nr_node->routes[1] = nr_route;
- }
- if (nr_node->routes[2].quality > nr_node->routes[1].quality) {
- switch (nr_node->which) {
- case 1: nr_node->which = 2;
- break;
-
- case 2: nr_node->which = 1;
- break;
-
- default:
- break;
- }
- nr_route = nr_node->routes[1];
- nr_node->routes[1] = nr_node->routes[2];
- nr_node->routes[2] = nr_route;
- }
+ re_sort_routes(nr_node, 0, 1);
+ re_sort_routes(nr_node, 1, 2);
case 2:
- if (nr_node->routes[1].quality > nr_node->routes[0].quality) {
- switch (nr_node->which) {
- case 0: nr_node->which = 1;
- break;
-
- case 1: nr_node->which = 0;
- break;
-
- default: break;
- }
- nr_route = nr_node->routes[0];
- nr_node->routes[0] = nr_node->routes[1];
- nr_node->routes[1] = nr_route;
- }
+ re_sort_routes(nr_node, 0, 1);
case 1:
break;
}
--
2.7.4
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [PATCH v3 2/2] net: netrom: nr_route: mark expected switch fall-throughs
2017-10-27 5:50 ` [PATCH v3 0/2] refactor code and mark expected switch fall-throughs Gustavo A. R. Silva
2017-10-27 5:51 ` [PATCH v3 1/2] net: netrom: nr_route: refactor code in nr_add_node Gustavo A. R. Silva
@ 2017-10-27 5:51 ` Gustavo A. R. Silva
2017-10-27 14:47 ` [PATCH v3 0/2] refactor code and " David Ranch
2017-11-01 11:46 ` David Miller
3 siblings, 0 replies; 24+ messages in thread
From: Gustavo A. R. Silva @ 2017-10-27 5:51 UTC (permalink / raw)
To: Ralf Baechle, David S. Miller
Cc: linux-hams, netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
---
Changes in v2:
None.
Changes in v3:
Update subject.
net/netrom/nr_route.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index fba4b4c..75e6ba9 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -265,6 +265,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
case 3:
re_sort_routes(nr_node, 0, 1);
re_sort_routes(nr_node, 1, 2);
+ /* fall through */
case 2:
re_sort_routes(nr_node, 0, 1);
case 1:
@@ -357,6 +358,7 @@ static int nr_del_node(ax25_address *callsign, ax25_address *neighbour, struct n
switch (i) {
case 0:
nr_node->routes[0] = nr_node->routes[1];
+ /* fall through */
case 1:
nr_node->routes[1] = nr_node->routes[2];
case 2:
@@ -526,6 +528,7 @@ void nr_rt_device_down(struct net_device *dev)
switch (i) {
case 0:
t->routes[0] = t->routes[1];
+ /* fall through */
case 1:
t->routes[1] = t->routes[2];
case 2:
--
2.7.4
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs
2017-10-27 5:50 ` [PATCH v3 0/2] refactor code and mark expected switch fall-throughs Gustavo A. R. Silva
2017-10-27 5:51 ` [PATCH v3 1/2] net: netrom: nr_route: refactor code in nr_add_node Gustavo A. R. Silva
2017-10-27 5:51 ` [PATCH v3 2/2] net: netrom: nr_route: mark expected switch fall-throughs Gustavo A. R. Silva
@ 2017-10-27 14:47 ` David Ranch
2017-10-27 19:48 ` Gustavo A. R. Silva
2017-11-01 11:46 ` David Miller
3 siblings, 1 reply; 24+ messages in thread
From: David Ranch @ 2017-10-27 14:47 UTC (permalink / raw)
To: Gustavo A. R. Silva, linux-hams, netdev
Cc: David S. Miller, Ralf Baechle, walter harms, Kevin Dawson,
Bernard, f6bvp, Thomas Osterried
Hello Gustavo,
I appreciate you working on keeping up the kernel and maintaining some
of the older feature areas like AX.25, Netrom, etc. Other than auditing
your code changes, can you tell me what you're changing? I've been
attempting to find who / where does regression tests for the Linus
kernel to potentially ADD test suites for this area. In the recent
past, we have seen a lot of toxicity creep into the kernel because no
one is testing their changes and backing out this toxic code out of
released Linux distributions takes a VERY long time.
I'm willing to try and help here but I really would like to follow some
team's guidelines of how they would like tests to be created, supported,
etc. Be it in VMs, containers, specific automation languages, etc.
--David
KI6ZHD
On 10/26/2017 10:50 PM, Gustavo A. R. Silva wrote:
> The aim of this patchset is firstly to refactor code in nr_route.c in order to make it
> easier to read and maintain and, secondly, to mark some expected switch fall-throughs
> in preparation to enabling -Wimplicit-fallthrough.
>
> I have to mention that I did not implement any unit test.
> If someone has any suggestions on how I could test this piece of code
> it'd be greatly appreciated.
>
> Thanks
>
> Changes in v2:
> - Make use of the swap macro and remove inline keyword as suggested by
> Walter Harms and Kevin Dawson.
>
> Changes in v3:
> - Update subject for both patches.
> - Add this cover letter as suggested by David Miller.
>
> Gustavo A. R. Silva (2):
> net: netrom: nr_route: refactor code in nr_add_node
> net: netrom: nr_route: mark expected switch fall-throughs
>
> net/netrom/nr_route.c | 62 ++++++++++++++++-----------------------------------
> 1 file changed, 19 insertions(+), 43 deletions(-)
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs
2017-10-27 14:47 ` [PATCH v3 0/2] refactor code and " David Ranch
@ 2017-10-27 19:48 ` Gustavo A. R. Silva
2017-10-28 17:53 ` David Ranch
0 siblings, 1 reply; 24+ messages in thread
From: Gustavo A. R. Silva @ 2017-10-27 19:48 UTC (permalink / raw)
To: David Ranch
Cc: linux-hams, netdev, David S. Miller, Ralf Baechle, walter harms,
Kevin Dawson, Bernard, f6bvp, Thomas Osterried
Hi David,
Quoting David Ranch <linux-hams@trinnet.net>:
> Hello Gustavo,
>
> I appreciate you working on keeping up the kernel and maintaining
> some of the older feature areas like AX.25, Netrom, etc. Other than
> auditing your code changes, can you tell me what you're changing?
> I've been attempting to find who / where does regression tests for
> the Linus kernel to potentially ADD test suites for this area. In
> the recent past, we have seen a lot of toxicity creep into the
> kernel because no one is testing their changes and backing out this
> toxic code out of released Linux distributions takes a VERY long time.
>
Here you can see the patch I'm proposing to refactor some code:
https://patchwork.kernel.org/patch/10029119/
It does not add any new functionality. It's just a small function that
helps to modularize and reduce the size of the code in the
nr_add_node() function.
The function I'm proposing (re_sort_routes) re-sort the routes in
quality order. It takes as arguments a pointer to the nr_node
structure which contains the routes within and the indexes of the
routes to re-sort.
This function also replaces a "manual" swap of the routes with a call
to the swap macro.
Thanks
--
Gustavo A. R. Silva
> I'm willing to try and help here but I really would like to follow
> some team's guidelines of how they would like tests to be created,
> supported, etc. Be it in VMs, containers, specific automation
> languages, etc.
>
> --David
> KI6ZHD
>
>
>
>
> On 10/26/2017 10:50 PM, Gustavo A. R. Silva wrote:
>> The aim of this patchset is firstly to refactor code in nr_route.c
>> in order to make it
>> easier to read and maintain and, secondly, to mark some expected
>> switch fall-throughs
>> in preparation to enabling -Wimplicit-fallthrough.
>>
>> I have to mention that I did not implement any unit test.
>> If someone has any suggestions on how I could test this piece of code
>> it'd be greatly appreciated.
>>
>> Thanks
>>
>> Changes in v2:
>> - Make use of the swap macro and remove inline keyword as suggested by
>> Walter Harms and Kevin Dawson.
>>
>> Changes in v3:
>> - Update subject for both patches.
>> - Add this cover letter as suggested by David Miller.
>>
>> Gustavo A. R. Silva (2):
>> net: netrom: nr_route: refactor code in nr_add_node
>> net: netrom: nr_route: mark expected switch fall-throughs
>>
>> net/netrom/nr_route.c | 62
>> ++++++++++++++++-----------------------------------
>> 1 file changed, 19 insertions(+), 43 deletions(-)
>>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs
2017-10-27 19:48 ` Gustavo A. R. Silva
@ 2017-10-28 17:53 ` David Ranch
2017-10-29 1:45 ` David Miller
0 siblings, 1 reply; 24+ messages in thread
From: David Ranch @ 2017-10-28 17:53 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: linux-hams, netdev, David S. Miller, Ralf Baechle, walter harms,
Kevin Dawson, Bernard, f6bvp, Thomas Osterried
Hello Gustavo,
Thanks for the reply. I do appreciate the work but we've had other
people contribute to keep things up to date but previous minor patches
broke parts of the AX.25 stack in strange ways. The fixes weren't hard
to repair or backout but due to the timing, various Linux distros based
their releases on the broken kernel code and it's taken a LONG time to
get things healthy for them. We need be able provide a test harness to
developers to unit test / regression test their proposed code ideally
AHEAD of the commit but at least after the commit.
I'm still failing to find any Linux groups that offer some sort of
automated build & test environment (Travis, Jenkins, etc) tracking
various kernel branches, etc. It's gotta be out there (many of them in
fact) but I'm struggling to find them.
For example, here is an excellent article about what *Intel* is doing
for their graphics drivers but I need something that the general
community can leverage for say various protocol stacks (TCP/IP, AX.25,
whatever):
https://lwn.net/Articles/735468/
From that article, it seems that maybe this could be a good place to start:
https://01.org/lkp
https://github.com/intel/lkp-tests
Looks like a good start but is that what the majority of the Linux
kernel folk use today? Is it the right group for non-scaled out unit
testing that I seek? I also think this email-centric approach might be
an overly broad approach with WAY too much noise for various development
areas.
Does anyone else have thoughts on this topic?
--David
KI6ZHD
On 10/27/2017 12:48 PM, Gustavo A. R. Silva wrote:
> Hi David,
>
> Quoting David Ranch <linux-hams@trinnet.net>:
>
>> Hello Gustavo,
>>
>> I appreciate you working on keeping up the kernel and maintaining some
>> of the older feature areas like AX.25, Netrom, etc. Other than
>> auditing your code changes, can you tell me what you're changing? I've
>> been attempting to find who / where does regression tests for the
>> Linus kernel to potentially ADD test suites for this area. In the
>> recent past, we have seen a lot of toxicity creep into the kernel
>> because no one is testing their changes and backing out this toxic
>> code out of released Linux distributions takes a VERY long time.
>>
>
> Here you can see the patch I'm proposing to refactor some code:
> https://patchwork.kernel.org/patch/10029119/
>
> It does not add any new functionality. It's just a small function that
> helps to modularize and reduce the size of the code in the nr_add_node()
> function.
>
> The function I'm proposing (re_sort_routes) re-sort the routes in
> quality order. It takes as arguments a pointer to the nr_node structure
> which contains the routes within and the indexes of the routes to re-sort.
>
> This function also replaces a "manual" swap of the routes with a call to
> the swap macro.
>
> Thanks
> --
> Gustavo A. R. Silva
>
>> I'm willing to try and help here but I really would like to follow
>> some team's guidelines of how they would like tests to be created,
>> supported, etc. Be it in VMs, containers, specific automation
>> languages, etc.
>>
>> --David
>> KI6ZHD
>>
>>
>>
>>
>> On 10/26/2017 10:50 PM, Gustavo A. R. Silva wrote:
>>> The aim of this patchset is firstly to refactor code in nr_route.c in
>>> order to make it
>>> easier to read and maintain and, secondly, to mark some expected
>>> switch fall-throughs
>>> in preparation to enabling -Wimplicit-fallthrough.
>>>
>>> I have to mention that I did not implement any unit test.
>>> If someone has any suggestions on how I could test this piece of code
>>> it'd be greatly appreciated.
>>>
>>> Thanks
>>>
>>> Changes in v2:
>>> - Make use of the swap macro and remove inline keyword as suggested by
>>> Walter Harms and Kevin Dawson.
>>>
>>> Changes in v3:
>>> - Update subject for both patches.
>>> - Add this cover letter as suggested by David Miller.
>>>
>>> Gustavo A. R. Silva (2):
>>> net: netrom: nr_route: refactor code in nr_add_node
>>> net: netrom: nr_route: mark expected switch fall-throughs
>>>
>>> net/netrom/nr_route.c | 62
>>> ++++++++++++++++-----------------------------------
>>> 1 file changed, 19 insertions(+), 43 deletions(-)
>>>
>
>
>
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs
2017-10-28 17:53 ` David Ranch
@ 2017-10-29 1:45 ` David Miller
2017-10-29 4:15 ` David Ranch
0 siblings, 1 reply; 24+ messages in thread
From: David Miller @ 2017-10-29 1:45 UTC (permalink / raw)
To: linux-hams; +Cc: garsilva, linux-hams, netdev, ralf, wharms, hal, f6bvp, thomas
From: David Ranch <linux-hams@trinnet.net>
Date: Sat, 28 Oct 2017 10:53:24 -0700
> Does anyone else have thoughts on this topic?
I think you are making a mountain out of a mole hill.
If you care so much about this, set things up so that entities such as
the kbuild test robot run whatever tests you think are necessary.
Otherwise, continually test the stack yourself and report any
regressions here as fast as you can.
If soemone can't be bothered to verify or test someone's change in 2
or 3 days, except in extreme circumstances, I absolutely refuse to
burdon the submitter and let their patches rot in the queue.
That's unacceptable.
That's the proper way to deal with this, without unreasonably
burdoning people who just want to keep the code across the tree modern
and more up to date.
Thank you.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs
2017-10-29 1:45 ` David Miller
@ 2017-10-29 4:15 ` David Ranch
2017-11-08 22:02 ` f6bvp
0 siblings, 1 reply; 24+ messages in thread
From: David Ranch @ 2017-10-29 4:15 UTC (permalink / raw)
To: David Miller
Cc: garsilva, linux-hams, netdev, ralf, wharms, hal, f6bvp, thomas
Hello David,
Thanks for the reply. I completely admit that there aren't many changes
going into this section of code. Unfortunately, we've had some nasty
breaks that took quite a long while to get fixed.
Can you point me in the direction of this kbuild test robot (URLs, etc)
so I can better understand if it makes sense to add tests there? For
example, do you know if it's "changed based" so only certain tests will
run if given files are updated?
--David
KI6ZHD
On 10/28/2017 06:45 PM, David Miller wrote:
> From: David Ranch <linux-hams@trinnet.net>
> Date: Sat, 28 Oct 2017 10:53:24 -0700
>
>> Does anyone else have thoughts on this topic?
>
> I think you are making a mountain out of a mole hill.
>
> If you care so much about this, set things up so that entities such as
> the kbuild test robot run whatever tests you think are necessary.
>
> Otherwise, continually test the stack yourself and report any
> regressions here as fast as you can.
>
> If soemone can't be bothered to verify or test someone's change in 2
> or 3 days, except in extreme circumstances, I absolutely refuse to
> burdon the submitter and let their patches rot in the queue.
>
> That's unacceptable.
>
> That's the proper way to deal with this, without unreasonably
> burdoning people who just want to keep the code across the tree modern
> and more up to date.
>
> Thank you.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs
2017-10-27 5:50 ` [PATCH v3 0/2] refactor code and mark expected switch fall-throughs Gustavo A. R. Silva
` (2 preceding siblings ...)
2017-10-27 14:47 ` [PATCH v3 0/2] refactor code and " David Ranch
@ 2017-11-01 11:46 ` David Miller
2017-11-01 17:34 ` Gustavo A. R. Silva
3 siblings, 1 reply; 24+ messages in thread
From: David Miller @ 2017-11-01 11:46 UTC (permalink / raw)
To: garsilva; +Cc: linux-hams, netdev, linux-kernel, ralf, wharms, hal
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Fri, 27 Oct 2017 00:50:57 -0500
> The aim of this patchset is firstly to refactor code in nr_route.c in order to make it
> easier to read and maintain and, secondly, to mark some expected switch fall-throughs
> in preparation to enabling -Wimplicit-fallthrough.
>
> I have to mention that I did not implement any unit test.
> If someone has any suggestions on how I could test this piece of code
> it'd be greatly appreciated.
Series applied, thank you.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs
2017-11-01 11:46 ` David Miller
@ 2017-11-01 17:34 ` Gustavo A. R. Silva
0 siblings, 0 replies; 24+ messages in thread
From: Gustavo A. R. Silva @ 2017-11-01 17:34 UTC (permalink / raw)
To: David Miller; +Cc: linux-hams, netdev, linux-kernel, ralf, wharms, hal
Quoting David Miller <davem@davemloft.net>:
> From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
> Date: Fri, 27 Oct 2017 00:50:57 -0500
>
>> The aim of this patchset is firstly to refactor code in nr_route.c
>> in order to make it
>> easier to read and maintain and, secondly, to mark some expected
>> switch fall-throughs
>> in preparation to enabling -Wimplicit-fallthrough.
>>
>> I have to mention that I did not implement any unit test.
>> If someone has any suggestions on how I could test this piece of code
>> it'd be greatly appreciated.
>
> Series applied, thank you.
Glad to help.
Thanks
--
Gustavo A. R. Silva
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs
2017-10-29 4:15 ` David Ranch
@ 2017-11-08 22:02 ` f6bvp
0 siblings, 0 replies; 24+ messages in thread
From: f6bvp @ 2017-11-08 22:02 UTC (permalink / raw)
To: David Ranch
Cc: David Miller, garsilva, linux-hams, netdev, ralf, wharms, hal, thomas
Hi all,
I just want to report that I applied the NetRom patch to most recent kernel. NetRom does not seem to be affected and connexion is doing well between my FPAC node f6bvp and f3kt.
73 de Bernard f6bvp
Sent from my iPhone
> Le 29 oct. 2017 à 05:15, David Ranch <linux-hams@trinnet.net> a écrit :
>
>
> Hello David,
>
> Thanks for the reply. I completely admit that there aren't many changes going into this section of code. Unfortunately, we've had some nasty breaks that took quite a long while to get fixed.
>
> Can you point me in the direction of this kbuild test robot (URLs, etc) so I can better understand if it makes sense to add tests there? For example, do you know if it's "changed based" so only certain tests will run if given files are updated?
>
> --David
> KI6ZHD
>
>
>> On 10/28/2017 06:45 PM, David Miller wrote:
>> From: David Ranch <linux-hams@trinnet.net>
>> Date: Sat, 28 Oct 2017 10:53:24 -0700
>>
>>> Does anyone else have thoughts on this topic?
>>
>> I think you are making a mountain out of a mole hill.
>>
>> If you care so much about this, set things up so that entities such as
>> the kbuild test robot run whatever tests you think are necessary.
>>
>> Otherwise, continually test the stack yourself and report any
>> regressions here as fast as you can.
>>
>> If soemone can't be bothered to verify or test someone's change in 2
>> or 3 days, except in extreme circumstances, I absolutely refuse to
>> burdon the submitter and let their patches rot in the queue.
>>
>> That's unacceptable.
>>
>> That's the proper way to deal with this, without unreasonably
>> burdoning people who just want to keep the code across the tree modern
>> and more up to date.
>>
>> Thank you.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v3 0/2] refactor code and mark expected switch fall-throughs
@ 2017-11-08 22:02 ` f6bvp
0 siblings, 0 replies; 24+ messages in thread
From: f6bvp @ 2017-11-08 22:02 UTC (permalink / raw)
To: David Ranch
Cc: David Miller, garsilva, linux-hams, netdev, ralf, wharms, hal, thomas
Hi all,
I just want to report that I applied the NetRom patch to most recent kernel. NetRom does not seem to be affected and connexion is doing well between my FPAC node f6bvp and f3kt.
73 de Bernard f6bvp
Sent from my iPhone
> Le 29 oct. 2017 ¨¤ 05:15, David Ranch <linux-hams@trinnet.net> a ¨¦crit :
>
>
> Hello David,
>
> Thanks for the reply. I completely admit that there aren't many changes going into this section of code. Unfortunately, we've had some nasty breaks that took quite a long while to get fixed.
>
> Can you point me in the direction of this kbuild test robot (URLs, etc) so I can better understand if it makes sense to add tests there? For example, do you know if it's "changed based" so only certain tests will run if given files are updated?
>
> --David
> KI6ZHD
>
>
>> On 10/28/2017 06:45 PM, David Miller wrote:
>> From: David Ranch <linux-hams@trinnet.net>
>> Date: Sat, 28 Oct 2017 10:53:24 -0700
>>
>>> Does anyone else have thoughts on this topic?
>>
>> I think you are making a mountain out of a mole hill.
>>
>> If you care so much about this, set things up so that entities such as
>> the kbuild test robot run whatever tests you think are necessary.
>>
>> Otherwise, continually test the stack yourself and report any
>> regressions here as fast as you can.
>>
>> If soemone can't be bothered to verify or test someone's change in 2
>> or 3 days, except in extreme circumstances, I absolutely refuse to
>> burdon the submitter and let their patches rot in the queue.
>>
>> That's unacceptable.
>>
>> That's the proper way to deal with this, without unreasonably
>> burdoning people who just want to keep the code across the tree modern
>> and more up to date.
>>
>> Thank you.
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2017-11-08 22:02 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-19 17:21 [PATCH 1/2] net: netrom: mark expected switch fall-throughs Gustavo A. R. Silva
2017-10-19 17:27 ` [PATCH 2/2] net: netrom: refactor code in nr_add_node Gustavo A. R. Silva
2017-10-20 8:57 ` walter harms
2017-10-20 8:57 ` walter harms
2017-10-20 16:06 ` Gustavo A. R. Silva
2017-10-20 16:54 ` walter harms
2017-10-20 23:09 ` Kevin Dawson
2017-10-23 0:41 ` Gustavo A. R. Silva
2017-10-23 1:08 ` [PATCH v2 " Gustavo A. R. Silva
2017-10-23 1:18 ` David Miller
2017-10-23 1:39 ` Gustavo A. R. Silva
2017-10-27 5:50 ` [PATCH v3 0/2] refactor code and mark expected switch fall-throughs Gustavo A. R. Silva
2017-10-27 5:51 ` [PATCH v3 1/2] net: netrom: nr_route: refactor code in nr_add_node Gustavo A. R. Silva
2017-10-27 5:51 ` [PATCH v3 2/2] net: netrom: nr_route: mark expected switch fall-throughs Gustavo A. R. Silva
2017-10-27 14:47 ` [PATCH v3 0/2] refactor code and " David Ranch
2017-10-27 19:48 ` Gustavo A. R. Silva
2017-10-28 17:53 ` David Ranch
2017-10-29 1:45 ` David Miller
2017-10-29 4:15 ` David Ranch
2017-11-08 22:02 ` f6bvp
2017-11-08 22:02 ` f6bvp
2017-11-01 11:46 ` David Miller
2017-11-01 17:34 ` Gustavo A. R. Silva
2017-10-23 16:19 ` Fwd: [PATCH v2 2/2] net: netrom: refactor code in nr_add_node David Ranch
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.