* Randy Dunlap <randy.dunlap@xxxxxxxxxx> wrote: > Ingo Molnar wrote: > > * Randy Dunlap <randy.dunlap@xxxxxxxxxx> wrote: > > > >> Ingo Molnar wrote: > >>> * Randy Dunlap <randy.dunlap@xxxxxxxxxx> wrote: > >>> > >>>> On Thu, 12 Mar 2009 12:26:21 -0400 Steven Rostedt wrote: > >>>> > >>>>> On Thu, 2009-03-12 at 09:17 -0700, Randy Dunlap wrote: > >>>>>> [adding cc:s] > >>>>>> > >>>>>> [same report for March 12] > >>>>>> > >>>>>> Randy Dunlap wrote: > >>>>>>> Stephen Rothwell wrote: > >>>>>>>> Hi all, > >>>>>>>> > >>>>>>>> Changes since 20090310: > >>>>>>> Building on i386 generates a ton of printk format warnings: > >>>>>>> > >>>>>>> kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'unsigned int' > >>>>>>> kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'unsigned int' > >>>>>>> kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 9 has type 'unsigned int' > >>>>>>> kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 10 has type 'unsigned int' > >>>>>>> kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 13 has type 'unsigned int' > >>>>>>> kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 14 has type 'unsigned int' > >>>>>>> kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 17 has type 'unsigned int' > >>>>>>> kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 18 has type 'unsigned int' > >>>>>>> kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 21 has type 'unsigned int' > >>>>>>> kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 22 has type 'unsigned int' > >>>>>>> > >>>>> I believe this is corrected in Ingo's tip tree. I changed %lu to %zu to > >>>>> handle the "sizeof()" case. The fix was suggested by Andrew Morton. > >>>> This build warning is still around (20090318). > >>>> Is the fix not in some branch that is imported into linux-next or what? > >>> be patient. > >>> > >>> Ingo > >> I think that 7 days is being patient for a simple build fix. > > > > s/build fix/harmless build warning fix > > 180+ lines of noise in a build log. > > > If you are interested in having a resolution you can git-merge the > > latest development tree yourself and you can get rid of that > > warning. > > > > Of course that way you'd expose yourself to even fresher code, > > potentially with much more serious breakages. > > > > It's a balance of freshness versus stability, and that balance is > > kept by maintainers. > > > > If you want the latest development code - go engage with the > > development trees directly. > > > > If you want something that is relatively new (i.e. 1-2 weeks fresh) > > but works on the range of systems we test, use what you get in > > linux-next. > > > > It's your choice which one you pick. > > > > But you cannot have both. > > > > If you genuinely think you can have it both, by all means i > > encourage you to try it - it's all open source so you can run your > > own tree. Just please dont feel entitled to demand it from others. > > Thanks for the explanation. That's what I tried to ask for > to begin with. I guess that I have a language problem. Note, six hours ago i reintegrated all the auto-next branches so this warning should be gone in the next linux-next iteration - they are now traded for brand new bugs ;-) Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
