Zircon is a object-based kernel. User mode code almost exclusively interacts with OS resources via object handles. A handle can be thought of as an active session with a specific OS subsystem scoped to a particular resource.
Zircon actively manages the following resources:
Some kernel objects wrap one or more LK-level constructs. For example the Thread object wraps one thread_t
. However the Channel does not wrap any LK-level objects.
Kernel objects are ref-counted. Most kernel objects are born during a syscall and are held alive at refcount = 1 by the handle which binds the handle value given as the output of the syscall. The handle object is held alive as long it is attached to a handle table. Handles are detached from the handle table closing them (for example via sys_close()
) which decrements the refcount of the kernel object. Usually, when the last handle is closed the kernel object refcount will reach 0 which causes the destructor to be run.
The refcount increases both when new handles (referring to the object) are created and when a direct pointer reference (by some kernel code) is acquired; therefore a kernel object lifetime might be longer than the lifetime of the process that created it.
A kernel object is implemented as a C++ class that derives from Dispatcher
and that overrides the methods it implements. Thus, for example, the code of the Thread object is found in ThreadDispatcher
. There is plenty of code that only cares about kernel objects in the generic sense, in that case the name you'll see is fbl::RefPtr<Dispatcher>
.
In principle, kernel objects do not have an intrinsic notion of security and do not do authorization checks; security rights are held by each handle. A single process can have two different handles to the same object with different rights.