This is an (incomplete) list of some of the stuff we want to look at doing.

If you're interested in hacking on any of these, please contact the list first
for some pointers and/or read HACKING and doc/CodingStyle.

0.7 release
-----------

 o separate debug info stuff
 o debian build stuff
 o side-by-side opreport output (--compare - needs UI spec)
 o thread profiling (Ka is on this)
 o per-cpu profiling
 o we show a header but not column headers for image report
 o lib-image: and image: behavior depend on --separate=, if --separate=library
  opreport "lib-image:*libc*" --merge=lib works but not
  opreport "image:*libc*" --merge=lib whilst the behavior is reversed if
  --separate==none. Must we take care ?

0.8 release
-----------

 o merge BRANCH_CALLGRAPH

Before 1.0 big stuff
--------------------

 o add support for samples not belonging to any symbols probably through
   artificially created symbols
 o opdiff
 
Before 1.0 little stuff
-----------------------

 o oprof_start dialog size is too small initially
 o oprof_start key movement through events doesn't change help text
 o add -Wdeclaration-after-statement for $CC
 o GUI still has a physical-counter interface, should have a general one
   like opcontrol --event
 o test opannotate -s -a on an application containing relative path debug
  info and profiled in another directory than the application build once.
  can objdump retrieve the source file and if no can we work-around ?
 o implement pp_interface alias
 o look if we must remove help_str support from libopt++
 o move oprofiled.log to OP_SAMPLE_DIR/current ?
 o OPD_MAX_MODULES is stupid, use a list instead
 o improve the *non* verbose daemon log to be a bit more informative
 o --buffer-size is useless on 2.5 without tuning of watershed
 o is --reset racy ? it's certainly too slow ...
 o oprof_start: check lib samples when kernel samples checkbox is checked
 o fix /dev/null mappings (see sf) (I've seen this once - john)
 o mask SIGTERM over critical daemon operations that could corrupt sample files
 o pp tools must handle samples count overflow (marked as (unsigned)-1)
 o verify if we can remove the ELF-based symbol size code
 o must we do setrlimit(RLIMIT_NOFILE, ...) for daemon ? Isn't already limited
  by the kernel itself ? - we must do this
 o when we dump stats for oprofiled, dump kernel-side values too (for 2.5)
 o lookup_dcookie can return ENAMETOOLONG but we can't hack it
   - a C++ rewrite can handle this, and also the rlimit problem via caching name id's
     and opening when necessary etc.
 o remove 2.2 / gcc 2.91 support ?
 o opannotate unhandled option: --base-dir
 o the way we show kernel modules in 2.5 is not very obvious - "/oprofile"

Documentation
-------------

 o more discussion of problematic code needs to go in the "interpreting" section. 
 o document gcc 2.95 and linenr info problems especially for inline functions
 o split doc into user's manual and hacking manual, document much more 
 o audit oprof_start for security + then document sudo

General checks to make
----------------------
 
 o check chroot() processes and the path hash stuff
 o rgrep FIXME
 o valgrind (--show-reachable=yes --leak-check=yes)
 o audit to track unnecessary include <>
 o gcc 3.0/3.x compile
 o Qt2/3 check, no Qt check
 o verify builds (modversions, kernel versions, athlon etc.). I have the
  necessary stuff to check kernel versions/configurations on PIII core (Phil)
 o use nm and a little script to track unused function
 o test it to hell and back
 o compile all C++ programs with STL_port and test them
 o There is probably place of post profile tools where looking at errno will give better error messages.

Later
-----
 
 o I think we should have the ability to have *fixed* width headers, e.g. :

vma      samples  cum. samples  %           cum. %     symbol name             image name              app name
0804c350 64582    64582         35.0757     35.0757    odb_insert              /usr/loc...in/oprofiled /usr/local/oprofile-pp/bin/oprofiled

  Note the ellipsis
 o option xxx and negated option --no-xxx: we can hide them in --help and
  mention in the xxx option help string than the --no-xxx is allowed. Not
  really usefull if we have a little number of --no.
 o should we make the sighup handler re-read counter config and re-start profiling too ?
 o improve --smart-demangle
	o allow user to add it's own pattern in user.pat, document it.
	o hard code ${typename} regular definition to remove all current limitations (difficult, perhaps after 1.0 ?).
 o allow --event to take event numbers. (is it worth ?)
 o i18n. We need a good formatter, and also remember format_percent()
 o op_to_source --source-dir=~moz/src/oprofile/ --output-dir=op /usr/bin/oprofiled
   will fail because the ~ is not expanded (no space around it) (popt bug I say)
 o cpu names instead of numbers in 2.4 module/ ?
 o remove 1 and 2 magic numbers for oprof_ready
 o adapt Anton's patch for handling non-symbolled libraries ?
 o use standard C integer type <stdint.h> int32_t int16_t etc.
 o opcontrol --save should allow to backup binary, see subject "features to make oprofile easier to use" on mail list
 o event multiplexing for real
 
o profile the NMI handler code
 
o merge sample files into one big report (like vtune can do repeated runs)

oprof_report:

IMHO this app isn't near what we really want. There's no point doing this
GUI until we can give it some real power. Let's concentrate on making the
command-line tools as good as possible first. 
- folderview of sample files + sessions in the gui itself (later ?)
- disassembly. form "+0x8b" for intra-symbol samples optionally, on by default?
- tune and test hotspot
- source (later ?)
 
