* 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 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. 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
