2LS thread_blockon now takes the uthread*
[akaros.git] / Documentation / processes.txt
index 8f3bc22..8cc44c3 100644 (file)
@@ -170,9 +170,11 @@ TLS/TCB descriptor and the floating point/silly state (if applicable) in the
 user-thread control block, and do whatever is needed to signal vcore0 to run the
 _S context when it starts up.  One way would be to mark vcore0's "active thread"
 variable to point to the _S thread.  When vcore0 starts up at
-_start/hart_entry() (like all vcores), it will see a thread was running there
-and restart it.  This will need to have some special casing for the FP/silly
-state.
+_start/vcore_entry() (like all vcores), it will see a thread was running there
+and restart it.  The kernel will migrate the _S thread's silly state (FP) to the
+new pcore, so that it looks like the process was simply running the _S thread
+and got notified.  Odds are, it will want to just restart that thread, but the
+kernel won't assume that (hence the notification).
 
 In general, all cores (and all subsequently allocated cores) start at the elf
 entry point, with vcoreid in eax or a suitable arch-specific manner.  There is
@@ -180,13 +182,13 @@ also a syscall to get the vcoreid, but this will save an extra trap at vcore
 start time.
 
 Future proc_runs(), like from RUNNABLE_M to RUNNING_M start all cores at the
-entry point, including vcore0.  The saving of a _S context to vcore0's notif_tf only happens on
-the transition from _S to _M (which the process needs to be aware of for a
-variety of reasons).  This also means that userspace needs to handle vcore0
-coming up at the entry point again (and not starting the program over).  This is
-currently done in sysdeps-ros/start.c, via the static variable init.  Note there
-are some tricky things involving dynamically linked programs, but it all works
-currently.
+entry point, including vcore0.  The saving of a _S context to vcore0's notif_tf
+only happens on the transition from _S to _M (which the process needs to be
+aware of for a variety of reasons).  This also means that userspace needs to
+handle vcore0 coming up at the entry point again (and not starting the program
+over).  This is currently done in sysdeps-ros/start.c, via the static variable
+init.  Note there are some tricky things involving dynamically linked programs,
+but it all works currently.
 
 When coming in to the entry point, whether as the result of a startcore or a
 notification, the kernel will set the stack pointer to whatever is requested
@@ -233,7 +235,7 @@ to _S.  The kernel will rip it out of your vcore list.  A process can yield its
 cores in any order.  The kernel will "fill in the holes of the vcoremap" for any
 future new cores requested (e.g., proc A has 4 vcores, yields vcore2, and then
 asks for another vcore.  The new one will be vcore2).  When any core starts in
-_M mode, even after a yield, it will come back at the hart_entry()/_start point.
+_M mode, even after a yield, it will come back at the vcore_entry()/_start point.
 
 Yield will normally adjust your desired amount of vcores to the amount after the
 calling core is taken.  This is the way a process gives its cores back.
@@ -345,8 +347,8 @@ bother sending IPIs, and if an IPI is sent before notifications are masked,
 then the kernel will double-check this flag to make sure interrupts should
 have arrived.
 
-Notification unmasking is done by setting the notif_enabled flag (similar to
-turning interrupts on in hardware).  When a core starts up, this flag is off,
+Notification unmasking is done by clearing the notif_disabled flag (similar to
+turning interrupts on in hardware).  When a core starts up, this flag is on,
 meaning that notifications are disabled by default.  It is the process's
 responsibility to turn on notifications for a given vcore.
 
@@ -423,7 +425,7 @@ which we aren't even sure is a problem yet.
 We considered having the kernel be aware of a process's transition stacks and
 sizes so that it can detect if a vcore is in a notification handler based on
 the stack pointer in the trapframe when a trap or interrupt fires.  While
-cool, the flag for notif_enabled is much easier and just as capable.
+cool, the flag for notif_disabled is much easier and just as capable.
 Userspace needs to be aware of various races, and only enable notifications
 when it is ready to have its transition stack clobbered.  This means that when
 switching from big user-thread to user-thread, the process should temporarily
@@ -463,8 +465,8 @@ wanted, but the vcore did not get truly interrupted since its notifs were
 disabled.  There is a race between checking the queue/bitmask and then enabling
 notifications.  The way we deal with it is that the kernel posts the
 message/bit, then sets notif_pending.  Then it sends the IPI, which may or may
-not be received (based on notif_enabled).  (Actually, the kernel only ought to
-send the IPI if notif_pending was 0 (atomically) and notif_enabled is 1).  When
+not be received (based on notif_disabled).  (Actually, the kernel only ought to
+send the IPI if notif_pending was 0 (atomically) and notif_disabled is 0).  When
 leaving the transition stack, userspace should clear the notif_pending, then
 check the queue do whatever, and then try to pop the tf.  When popping the tf,
 after enabling notifications, check notif_pending.  If it is still clear, return