* Jiri Olsa <jo...@redhat.com> wrote:
> On Wed, Apr 23, 2014 at 03:14:33PM +0200, Ingo Molnar wrote:
> >
> > (Just reporting two bugs I found today - unrelated to your the
> > perf/urgent pull request.)
> >
> > 1)
> >
> > Even when the most modern unwind library is found, the autodetection
> > is spammy:
> >
> >
> > Auto-detecting system features:
> > ... dwarf: [ on ]
> > ... glibc: [ on ]
> > ... gtk2: [ on ]
> > ... libaudit: [ on ]
> > ... libbfd: [ on ]
> > ... libelf: [ on ]
> > ... libnuma: [ on ]
> > ... libperl: [ on ]
> > ... libpython: [ on ]
> > ... libslang: [ on ]
> > ... libunwind: [ on ]
> > ... libdw-dwarf-unwind: [ on ]
> > ... DWARF post unwind library: libunwind
> >
> > The 'DWARF post unwind library' line is somewhat superfluous. I
> > realize that it prints out the library selected - but that's obvious
> > from the 'libdw-dwarf-unwind' line above it already, right?
>
> nope, the on/off output is only whats detected in system,
> you've got both libunwind and libdw-dwarf-unwind detected
>
> libunwind is default unless you use NO_LIBUNWIND=1
Okay, so the problem is that we don't have a simple binary-state
feature in this case, but three possible states: 'libunwind', or
'libdw-dwarf-unwind', or 'OFF', right?
If so then the solution would be to replace those 3 last lines with
just this line:
... DWARF unwind library: [ libunwind ]
Where 'libunwind' is printed in green (like the 'on' lines are
printed). If there's no suitable library available then output:
... DWARF unwind library: [ OFF ]
Because the user looking at the output is really only interested in
'is an unwind library available', and maybe in 'which one'.
Is there preference between library choices? I.e. is 'libunwind'
preferred over 'libdw-dwarf-unwind', or the other way around? If yes
then if we pick an inferior library we could print it in yellow color
- and only use green if it's the 'best' choice.
That way the color codes also still keep working: red means problem,
green means OK, yellow something inbetween.
But in any case we should try to keep the 'one feature, one line'
fundamental output concept.
( Under V=1 we can output whatever details might be useful to
developers, there's no restriction on what to output there. )
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
