Update TODO

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]