OBJECTS

• A direct pointer to the struct

  These are used by the oz_knl_... modules and are the quickest path to an object. For every such pointer that exists the reference count of the object is incremented. So if you look at an object's reference count, you can tell how many pointers there are out there pointing to it. Most objects are freed off when the reference count goes to zero. Some stay around like devices and logical names. These pointers generally do not have any associated thread or process context associated with them so they can be passed from thread to thread and process to process without worry.

  The structs are generally opaque outside of their defining module. This is sometimes a pain but mostly it makes things easy to change. For example, the thread object contents is only known by the oz_knl_thread.c module. Everywhere else it is a void * definition. Now in case you accidentally pass a thread object pointer where a process object pointer should go, a runtime check (ie, crash) will occur as the routines check the object type (the first value in all the objects) before proceeding. (This can be nopped for speed by changing one macro definition).

• An handle

  Each process in the system has a table of handles. Each entry in the table can contain a pointer to an object. So, for instance, handle 1 could point to the image that was loaded into a process, handle 2 could be some event flag, etc. There are routines (oz_knl_handle_...) that manipulate the handles. They require a certain process context to perform an handle-to-pointer translation.

  Handles can be directly manipulated by user mode code. They are only translated to pointers when in kernel mode. Of course, handles can be manipulated by kernel mode code as well.

• Logical name

  An logical name can be equated to a pointer. This makes it easy to pass things from one process to another. For example, one process could open a pipe, then assign the I/O channel to a logical name, then another process could access the I/O channel from the logical name and thus the two processes can communicate. There are routines (oz_knl_logname_...) that translate logical names to object pointers and vice versa. Confusingly, logical names themselves are objects, so you can have a logical name that points to a logical name object.

Here are the objects in the kernel:

• AST - Asynchronous System Traps - these are queued to a thread to interrupt it and cause it to call a particular routine. Typically these are used to finish up an I/O operation.
• Event flags - These are what threads can wait for. So a thread may start an I/O specifying that an event flag be set when the I/O completes. Then when the thread needs the results of the I/O, it waits for the event flag.
• Process - this is a virtual addressing space, images can be loaded in it, files can be mapped to it, new memory can be allocated to it. Also, threads can be attached to it to execute instructions.
• Security attributes - who can access an object
• Security keys - what objects a thread can access
• Section - a block of memory, such as the read-only section of an image file or a shared global memory section, or a process' heap or a thread's stack
• Thread - a 'virtual cpu' that executes instructions. These are scheduled on a priority basis.
• Kernel thread - a version of a thread that only executes in kernel mode and is generally not associated with any particular process
• Exit handler - a routine that is called when a thread exits
• Device unit
• Device driver
• Device class
• I/O Operation
• I/O channel
• I/O select
• Low IPL
• Handle table
• Image
• Logical name
• Logical name search
• Condition handler
• Timer
• I/O Parsing
• Section lock
• Disk partition
• User
• Job
• Quota
• Disk cache