Re: [PATCH] x86: add the debugfs interface for the sysprof tool

[John Levon <levon@movementarian.org>]

Obviously I hold no sway here, so there's little point in my continuing
to try and fight this madness, but I have to say my piece. Don't worry,
I'll leave it after this - I know Ingo always gets his way.

On Sat, Feb 23, 2008 at 12:37:24PM +0100, Ingo Molnar wrote:

> and ask him to try oprofile and then to try sysprof as a comparison - to 
> and figure in which app and which function the overhead is.

Now work out whether this is a result of the kernel code or not. Whilst
there's probably no point me stating this: I object most strenuously to
the idea of merging duplicate code that does part of what oprofile does.

Soren wrote sysprof when he tried an earlier version of oprofile and
found it slightly non-obvious. Instead of doing any of these things:

- complaining to the oprofile list
- checking a version of oprofile written in the last two years
- fixing oprofile user space to be more obvious

he just went on right ahead and re-implemented it so he could write a
GUI on top of it. That *exact same GUI*  could have been on top of
oprofile. Usability problems with opcontrol or opreport could have been
reported (or even - gosh - fixed). Soren was too lazy.

It seems the same applies to you and Arjan, at least.

> It's 200 lines of pretty well isolated code for something that is 
> already much more usable to me than 10 years of oprofile. Really, i'd 
> much rather take 200 lines of poor kernel code written by a userspace 
> developer for stuff that _already works better_, than to have ~2000 
> lines of oprofile code and an unusable (to me) user-space tool written 
> by kernel developers.

I honestly can't believe that you're telling me you'd rather have more
kernel code than make some tweaks (which, by the way, you have NEVER
complained about to me or to the oprofile mailing list until now)
to a shell script. Specifically:

>   [ Newbie: WTF, no GUI tool? ]

Wrong. It's shipped with a (rather poor) GUI pretty much since
inception. More recently, there's been at least two GUIs. For example:

http://labs.o-hand.com/wp-content/uploads/2007/12/oprofileui.png

>   # opcontrol
> 
>   [ Newbie sees tons of output. User scratches head. After looking 
>     around, finds the following option listed:
>     "-s/--start       start data collection". That must be it! ]
> 
>   # opcontrol -s
>   No vmlinux file specified. You must specify the correct vmlinux file, e.g.
>   opcontrol --vmlinux=/path/to/vmlinux
>   If you do not have a vmlinux file, use
>   opcontrol --no-vmlinux
>   Enter opcontrol --help for full options
> 
>   [ Newbie: WTF? Doesnt oprofile think that what I want to do is to 
>     profile ... the currently running kernel, wherever a kernel is 
>     and whatever a vmlinux might be?? ]

Firstly, the distributions should have set this up automatically. That
they don't is a distributor bug. The sheer madness of Linux not leaving
a vmlinux file in a stable known location is hardly something oprofile
can be blamed for.

Secondly, not ONE PERSON INCLUDING YOU has EVER suggested to us that we
default to no vmlinux.

>   [ The newbie user eventually finds out that opcontrol help text is 
>     buggy and that -s does not mean --start, but --setup. ]

It's astonishing that you would know about this, complaining about this,
but not file a bug report. Same goes for the rest.

And once again, please explain how the buggy shell script has anything
to do with kernel code.

What, exactly, happened to scratching an itch? If everyone should be
hanging his head in shame, Ingo, why haven't you used your considerable
influence to find a maintainer for OProfile to fix the (until now,
private to you) issues you have with it? Shameful? Indeed.

john