# Zircon Kernel objects

[TOC]

Zircon is an 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:

+ processor time
+ memory and address spaces
+ device-io memory
+ interrupts
+ signaling and waiting

## Kernel objects for applications

### IPC
+ [Channel](/docs/reference/kernel_objects/channel.md)
+ [Socket](/docs/reference/kernel_objects/socket.md)
+ [FIFO](/docs/reference/kernel_objects/fifo.md)

### Tasks
+ [Process](/docs/reference/kernel_objects/process.md)
+ [Thread](/docs/reference/kernel_objects/thread.md)
+ [Job](/docs/reference/kernel_objects/job.md)
+ [Task](/docs/reference/kernel_objects/task.md)

### Scheduling
+ [Profile](/docs/reference/kernel_objects/profile.md)

### Signaling
+ [Event](/docs/reference/kernel_objects/event.md)
+ [Event Pair](/docs/reference/kernel_objects/eventpair.md)
+ [Futex](/docs/reference/kernel_objects/futex.md)

### Memory and address space
+ [Virtual Memory Object](/docs/reference/kernel_objects/vm_object.md)
+ [Virtual Memory Address Region](/docs/reference/kernel_objects/vm_address_region.md)
+ [bus_transaction_initiator](/docs/reference/kernel_objects/bus_transaction_initiator.md)
+ [Pager](/docs/reference/kernel_objects/pager.md)

### Waiting
+ [Port](/docs/reference/kernel_objects/port.md)
+ [Timer](/docs/reference/kernel_objects/timer.md)

## Kernel objects for drivers

+ [Interrupts](/docs/reference/kernel_objects/interrupts.md)
  + [Message Signaled Interrupts](/docs/reference/kernel_objects/msi.md)
+ [Resource](/docs/reference/kernel_objects/resource.md)
+ [Debuglog](/docs/reference/kernel_objects/debuglog.md)

## Kernel Object and LK
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 object lifetime
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.

## Dispatchers
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>`.

## Kernel Object security
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.

## See Also
[Handles](/docs/concepts/kernel/handles.md)