lkml.org 
[lkml]   [2009]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: sched: restore sanity

    * Peter Zijlstra <peterz@infradead.org> wrote:

    > On Sun, 2009-12-20 at 09:22 -0800, Joe Perches wrote:
    > > On Sun, 2009-12-20 at 16:19 +0100, Peter Zijlstra wrote:
    > > > On Sun, 2009-12-20 at 07:05 -0800, San Mehat wrote:
    > > > > >> Probably, but the rest is just as annoying, pr_* is crap.
    > > > > Oh? Out of curiosity whats wrong with it?
    > > > That's what should be asked of printk().
    > >
    > > pr_<level> offers some things printk cannot:
    > >
    > > o standardization, eliminates frequent missing KERN_ levels
    > > and missing/typo/misspelled module prefixes
    >
    > There's other ways of fixing that, one way is to make it a proper
    > function argument, like:
    >
    > printk(char level, char *fmt, ...);
    >
    > Which is something we have precedent for too in fprintf() and syslog().
    >
    > > o visually shorter, fewer chars used, less 80 char wrapping
    >
    > Fuck me senseless, visually less obvious too.
    >
    > > o finer grained ability to eliminate unnecessary messages
    > > for embedded systems
    >
    > How is that not possible with another solution.
    >
    > > o standardized mechanism to prefix messages with module/function
    >
    > Who fucking gives a shit, that is the very thing that made me send the
    > revert.
    >
    > > o eventual code reduction via use of a singleton instead of
    > > duplicated module/function names
    >
    > text reduction?
    >
    > > o eventual dynamic_debug styled control of prefix by
    > > module/function
    >
    > Feh, who cares, printk output simply shouldn't be frequent enough to
    > need filtering, there's much better solutions for that.
    >
    > > There are quite of number of arbitrarily named module wrapper
    > > macros and functions that build on printk.
    >
    > Then remove them all..
    >
    > Are you really arguing to fully deprecate printk()? If not this is all
    > going to be useless since I'll simply keep using printk().

    I dont mind that strongly but you (and Mike) objecting to it so forcefully
    clearly tips the balance against the pr_*() lines in sched.c so i've queued up
    your revert in the scheduler tree.

    ( I've Cc:-ed Linus and Andrew, in case they care one way or another. )

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2009-12-20 18:53    [W:0.027 / U:0.044 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site