From fe134ed8a2bff853cc274f8ac2cb2856b29b043a Mon Sep 17 00:00:00 2001 From: =?utf8?q?S=C3=B8ren=20Sandmann=20Pedersen?= Date: Mon, 31 Oct 2005 15:21:26 +0000 Subject: [PATCH] Update TODO --- TODO | 145 ++++++++++++++++++++++++++++++++++--------------------------------- 1 file changed, 74 insertions(+), 71 deletions(-) diff --git a/TODO b/TODO index 72c7803..898b6f9 100644 --- a/TODO +++ b/TODO @@ -15,6 +15,9 @@ Before 1.0.1: Before 1.2: +* Find out if the first sort order of a GtkTreeView column can be changed + programmatically. + * Find out why we get hangs with rawhide kernels. This only happens with the 'trace "current"' code. See this mail: @@ -169,77 +172,6 @@ Before 1.2: a text area + a radio buttons "text/html". When you flick them, the text area is automatically updated. -- Fixing the oops in kernels < 2.6.11 - - - Probably just require 2.6.11 (necessary for timer interrupt - based anyway). - - - Make the process waiting in poll() responsible for extracting - the backtrace. Give a copy of the entire stack rather than doing - the walk inside the kernel. - - New model: - - Two arrays, - one of actual scanned stacks - one of tasks that need to be scanned - One wait queue, - wait for data - - - in read() wait for stack data: - scan_tasks() - if (!stack_data) - return -EWOULDBLOCK; - - in poll() - while (!stack data) { - wait_for_data(); - scan_tasks(); - } - return READABLE; - - scan_tasks() is a function that converts waiting - tasks into data, and wakes them up. - - - in timer interrupt: - - if (someone waiting in poll() && - current && current != that_someone && - current is runnable) - { - stop current; - add current to queue; - wake wait_for_data; - } - - This way, we will have a real userspace process - that can take the page faults. - - - - Different approach: - - pollable file where a regular userspace process - can read a pid. Any pid returned is guaranteed to be - UNINTERRUPTIBLE. Userspace process is required to - start it again when it is done with it. - - Also provide interface to read arbitrary memory of - that process. - - ptrace() could in principle do all this, but - unfortunately it sucks to continuously - ptrace() processes. - - - Yet another - - Userspace process can register itself as "profiler" - and pass in a filedescriptor where all sorts of - information is sent. - - - could tie lifetime of module to profiler - - could send "module going away" information - - Can we map filedescriptors to files in - a module? - - Find out how gdb does backtraces; they may have a better way. Also find out what dwarf2 is and how to use it. Look into libunwind. It seems gdb is capable of doing backtraces of code that neither has @@ -488,6 +420,77 @@ Later: DONE: +- Fixing the oops in kernels < 2.6.11 + + - Probably just require 2.6.11 (necessary for timer interrupt + based anyway). + + - Make the process waiting in poll() responsible for extracting + the backtrace. Give a copy of the entire stack rather than doing + the walk inside the kernel. + + New model: + - Two arrays, + one of actual scanned stacks + one of tasks that need to be scanned + One wait queue, + wait for data + + - in read() wait for stack data: + scan_tasks() + if (!stack_data) + return -EWOULDBLOCK; + + in poll() + while (!stack data) { + wait_for_data(); + scan_tasks(); + } + return READABLE; + + scan_tasks() is a function that converts waiting + tasks into data, and wakes them up. + + - in timer interrupt: + + if (someone waiting in poll() && + current && current != that_someone && + current is runnable) + { + stop current; + add current to queue; + wake wait_for_data; + } + + This way, we will have a real userspace process + that can take the page faults. + + + - Different approach: + + pollable file where a regular userspace process + can read a pid. Any pid returned is guaranteed to be + UNINTERRUPTIBLE. Userspace process is required to + start it again when it is done with it. + + Also provide interface to read arbitrary memory of + that process. + + ptrace() could in principle do all this, but + unfortunately it sucks to continuously + ptrace() processes. + + - Yet another + + Userspace process can register itself as "profiler" + and pass in a filedescriptor where all sorts of + information is sent. + + - could tie lifetime of module to profiler + - could send "module going away" information + - Can we map filedescriptors to files in + a module? + * Make sure sysprof-text is not linked to gtk+ * Consider renaming profiler.[ch] to collector.[ch] -- 2.7.4