i found out about this particular issue just today, when i wrote this
mail, so consider this as my bugreport.
And i have to say, most of the usability deficits in oprofile are very
obvious, so consider this as a general "the oprofile commands suck in
almost every detail" bugreport. Tools should fundamentally be
one-stop-shops. I personally wouldnt mind the lack of a GUI at all if
the command line tool was _obvious to use_. If the principle was: get
the current histogram to the user. A tool should work _hard_ to get
something (_anything_) useful out by default. Transparently start up any
background state and procesing that is needed - and hide it as much as
possible. Try to figure out where the vmlinux is, if there's any. Do
_not_ put the user through any extra chores if not absolutely necessary.
Display information that tells the user what happened. Etc., etc. -
these are all basic principles.
imagine if the "ls" command, instead of listing files, showed 60 lines
of options, and when i picked "-l" it would, instead of listing files
already, ask me: "do you really mean the current filesystem?". And if i
said "list whatever filesystem i wanted" then it would also say "because
dm-crypt is not configured into the kernel I cannot display encrypted
information, use me with --no-crypt".
and as i sit here, i tried "opreport" once again, to just see what it
does by default. It just hung there, displaying nothing. For minutes.
Then i got suspicious and straced it. It loops in stat()s in one huge
directory that has amassed more than 20 thousand sample files in the
last few hours. This is such a basic usecase, tell me that this never
happened to you and that nobody ever came to the idea to display "sorry,
this might take a few minutes, 10% of the files are processed so far"
sort of feel-good messages to the user?
but generally i cannot fix and report and fight over all the crap that
people do - that would mean i'd have to complain about Linux all day,
non-stop. What i can do is to tell apart the better solutions from the
worse solutions when they get submitted to me. And guess what? One
little isolated 200 lines patch in x86.git and the people who sat on
their accomplishments for years are up in arms and oppose it. I must be
doing something right i guess :-/
Ingo
--
