* "L. Alberto Giménez" <agimenez@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > - All such variables need proper locking, as they can be re-entered > > from multiple CPUs (while local stack variables cannot and generally > > dont need such locking). Moving them to file scope makes sure it's > > all visible and makes sure proper locking is done. > > The same thing about visibility applies as above. Moreover, I can't > see any explicit lock inside the main.c file. [...] It's implicit - all bootup execution is serialized. So it's double important to make any global state clearly visible - should any of this be pushed to async bootup init functions (which would require the addition of a lock). > > All in one, there's a constant trend away from statics at function > > scope. It can be done correctly but is subtly fragile for the above > > reasons. > > Indeed it may be fragile. And I'm sure that you've faced tons of bugs > because of declaring static variables in funcion scope and not having > it in mind when using those variables. I'm just a newbie and I have > not faced serious challenges about kernel development, but I think > that those "sanity" things should be fixed (I'm kind of standards > taliban :) ), but I need your expertise to know *how* to fix it, from > the point of view of semantics and not just syntax. I think it's subtly wrong if you try to 'fix a warning', as the subject line already says it. Warnings are not something that should be 'fixed' - they are just a sign of some sort of trouble: 1- bug/limitation in the tool (Sparse) 2- uncleanliness in the source code 3- bug in the source code here it seems to be case #1, as file scope statics are perfectly fine, even if used by a single function. Ingo -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
