Re: next steps

[Richard J Moore <richardj_moore@uk.ibm.com>]

Frank, under improving kprobes I would add:

1) dprobes or a scalable mechanism for performance tracing, but not one
which throws away what we have unless it truly supersedes it
2) watchpoint probes if these aren't already there. This is the capability
to place a probe on a data location. Internally it uses the debug
registers. If this isn't there we do have the patch since this was part of
the original dprobes.
3) add back the ability to place probes in a code location before the
module is loaded. This capability comes automatically with the user-space
probes since probes are tracked by (inode, offset) and fixed up via
readpage() then the code is paged in.  We used to have this capability for
kernel modules. It relied on patches in insmod. Clearly this is useful
especially when wanting to capture initialization module problems.
4) Finally I'd request that we re-instate the SysRq function to disable all
probes instantly. This again was part of the original dprobes and proved
its worth when intensive tracing locked out the command line.

Apart from 1) all of these are simple modification for which the code has
all ready been written.

- -
Richard J Moore
IBM Advanced Linux Response Team - Linux Technology Centre
MOBEX: 264807; Mobile (+44) (0)7739-875237
Office: (+44) (0)1962-817072


                                                                           
             "Frank Ch.                                                    
             Eigler"                                                       
             <fche@redhat.co                                            To 
             m>                        systemtap@sources.redhat.com        
             Sent by:                                                   cc 
             systemtap-owner                                               
             @sources.redhat                                           bcc 
             .com                                                          
                                                                   Subject 
                                       next steps                          
             20/09/2005                                                    
             16:50                                                         
                                                                           




Hi -

I see several broad directions for our project for the next few
months.  In no particular order:


- Improving kprobes:
  - djprobes
  - rcu kprobes
  - user-space probes
  - porting to any other interesting platforms

- Other event sources:
  - remaining dwarf probe point types (.callees etc.)
  - static instrumentation in kernel and user space
  - performance counters

- Tapset scripts:
  - VM
  - I/O
  - networking
  - glibc threading / locking
  - language interpreter events

- Translator:
  - statistics support
  - optimizations

- System testing:
  - over a range of probe sizes, complexity
  - over a range of machine sizes, complexity
  - over a range of kernel/compiler versions
  - static verification?

- Propaganda:
  - tutorial level documentation
  - worked out problem-solving examples
  - scripts that substitute for / combine existing procps type tools
  - script language customizations for emacs/vi


It is not necessary for each of us to continue within the same area
we've been working so far.  I'd like to hear whether people or groups
are interested in taking responsibility for particular line items, or
if they wish to suggest amendments.


- FChE