> > > Yes, but many types of hardware _REQUIRE_ reads to do something. So > > > "read that does nothing" is a requirement for some operations. > > > > > > As an example, a write is only guaranteed to have been finished if you > > > do a read of the same location back from it on some hardware busses. > > > The bus can reorder things, but a write/read of the same location can > > > not be reordered. > > > > > > Sometimes you have to do reads multiple times to get things to "stick". > > > > > > Other times reading from a location changes a state in the hardware > > > (horrid but HW designers aren't the brightest at times...) > > > > > > So you can NOT just remove reads without knowing that the hardware does > > > not require this. This is an issue where GCC "warnings" mean nothing as > > > gcc does not actually know what hardware does, or does not, do for many > > > things. > > > > > > thanks, > > > > > > greg k-h > > > > thank you for explanation, my hardware knowledge is poor:( > > Sorry for noise. > > > > fabio > > > I suspected that removing those variables could have been a source of troubles > (but I was thinking of possible side effects on internal kernel's data, not of > hardware related idiosyncrasies), however I think that you did well to point > it out because: > > 1) We learned something new from Greg; yes that's been very good for me > 2) I learned that, for the purpose of finding definitions, vim's ctrl-] is not > the right way to work out the problem. 3) I learned that with ctrl-] in vim one could (in some misterious conditions) see a function definition :-D It seems that you know more than me about vim, I make intensive use of grep for finding function defs and usages in code. > > If you have time, I'd appreciate some comments on the topic of line (2). > > Thanks, > > Fabio > > > thank you, fabio
