This is a brief list of plans (often vague) I've had in mind for the utrace
infrastructure, and a few ideas about them.  Notably not included here is
anything about a higher-level interface, which is a separate subject.
These here are issues in the utrace infrastructure itself and things at the
low level that could be added to augment it.

Please contact me for more information and/or if you start working on any
of these things (or anything else based on utrace).

	--Roland McGrath <roland@redhat.com>


* Stability
** Torture tests via ptrace, ensure no regressions from old kernel ptrace,
   no leaks, no crashes

* Performance
** measurement vs old ptrace
** overhead measurement, profiling
** scaling issues
*** Sharing
    I've long thought that for large numbers of threads being traced by the
    same set of engines using the same parameters, there should be a way to
    have them share the utrace and utrace_attached_engine structures, so
    there is no per-pthread memory use when tracing many threads and
    treating them all alike.  Many details have to be figured out to make
    that happen.  The memory use and other kinds of overhead should be
    thoroughly analyzed before pursuing any particular scheme to reduce
    overhead and improve scalability.

* Engine interaction issues
** soft quiesce
*** Need form of quiesce w/o TIF_SIGPENDING, don't break interruptible waits
*** Only prevent resume to user, signal processing
*** User regs only readable, not writable, maybe not all visible(?)
*** Only report_syscall, get_signal are completely safe points for user regs
** inject_signal/report_quiesce interface unsatisfactory
*** w/o queuing, one engine gets EAGAIN if another has injected
*** injecting engine should see competing injection
*** perhaps punt inject_signal and make report_quiesce like report_signal?
** callback order

* Extension events
** low-level trigger, report callback at safe point (utrace_get_signal)
*** use this for single-step trap, breakpoint traps, page fault
**** generic signal-based machine trap call-in?
** allow modules to register event types, named in tree structure (kobject)
*** specify # of data words?
*** exported notifier for {,un}register_event
*** sysfs access to tree of event types

* mmap change event
** maybe just an extn event?

* Global tracing
** Allow a type of engine attached to no particular thread.
*** cannot use UTRACE_ACTION_STATE_MASK flags
*** syscall tracing would require TIF_SYSCALL_TRACE on every thread

* shadow pte
** install per-thread page table tree in a debugged thread
** enables vm watchpoints, nondestructive breakpoint insertion,
   per-thread breakpoints, etc.
** tailor interface to keep vm issues simple, e.g. punt affected threads to
   debugger when normal mm page table is updated.
** share page tables as much as possible with real mm
** much to be figured out

* Exploit more hardware support
** hw-breakpoint (Alan Stern)
*** more arch ports
*** utrace front-end to hw-breakpoint
*** utrace extension events as callback
** block step
   Some hardware can support block-step as well as single-step.
   Implement it where possible.  Already done for x86, ia64.
   Done modulo nits for powerpc but not upstream yet.
** Hardware branch tracing support
   Some processors have various features for recording branch history in
   various ways.  Survey such features and figure out how to expose them as
   per-thread and (if possible) in machine-independent terms.

* Breakpoint assistance
** see systemtap mailing list discussions (cf uprobes)
** provide stepcopy for single-step emulation on lacking hardware

* sigwait event