On 8/1/2018 10:03 PM, Stephen Hemminger wrote:

On Wed, 1 Aug 2018 18:03:04 +0000
Yongseok Koh [off-list ref] wrote:

quoted

quoted

On Jul 31, 2018, at 11:07 AM, Stephen Hemminger [off-list ref] wrote:

On Tue, 31 Jul 2018 18:48:40 +0200
Adrien Mazarguil [off-list ref] wrote:
  

quoted

On Tue, Jul 31, 2018 at 09:30:54AM -0700, Stephen Hemminger wrote:  

quoted

Declaring variables as register in C is a leftover from an earlier
era (like cassette tape decks in cars).    

I don't agree here. It's a hint for compilers and developers that the
address of such variables won't be needed (and cannot be taken) to enable
whatever optimizations are possible knowing this.

Somewhat like inline functions, it's not a forced optimization, just a
useful hint that shouldn't hurt if used wisely.

Besides, cassette decks are not dead yet :)  

If you look at the code, that is not how register is being used (ie. don't take
address of this). It seems like an attempt at optimization.  

I know compilers are smart enough and the occurrences in mlx4/5 were made from
my old fashioned habit. But, I don't see any urgency to push this patch in RC
stage even though I'm 99% sure that it is harmless. And in general I don't even
understand why we can't live with that if it isn't harmful (or a violation) but
informative. I mean no badness but at least one goodness :-)

Thanks,
Yongseok

Sure, this is intended for next release not rc stage.
Just trying to clean up code base where I see it.

I agree with Yongseok, at worst they show the intention of the developer, I
don't see motivation to remove them unless they are doing something wrong, which
seems not the reason of this patch.

And although I found some information that says "register" ignored completely
for gcc, I can see it differs when optimization disabled.
I am not saying practically it differs, since we enable optimization expect from
debugging, most probably there is no practical difference between having the
keyword or not, but what I am trying to say is it not completely ignored either.