1# Zircon Kernel objects
2
3[TOC]
4
5Zircon is a object-based kernel. User mode code almost exclusively interacts
6with OS resources via object handles. A handle can be thought of as an active
7session with a specific OS subsystem scoped to a particular resource.
8
9Zircon actively manages the following resources:
10
11+ processor time
12+ memory and address spaces
13+ device-io memory
14+ interrupts
15+ signaling and waiting
16
17## Kernel objects for applications
18
19### IPC
20+ [Channel](objects/channel.md)
21+ [Socket](objects/socket.md)
22+ [FIFO](objects/fifo.md)
23
24### Tasks
25+ [Process](objects/process.md)
26+ [Thread](objects/thread.md)
27+ [Job](objects/job.md)
28+ [Task](objects/task.md)
29
30### Signaling
31+ [Event](objects/event.md)
32+ [Event Pair](objects/eventpair.md)
33+ [Futex](objects/futex.md)
34
35### Memory and address space
36+ [Virtual Memory Object](objects/vm_object.md)
37+ [Virtual Memory Address Region](objects/vm_address_region.md)
38+ [bus_transaction_initiator](objects/bus_transaction_initiator.md)
39
40### Waiting
41+ [Port](objects/port.md)
42
43## Kernel objects for drivers
44
45+ [Interrupts](objects/interrupts.md)
46+ [Resource](objects/resource.md)
47+ [Log](objects/log.md)
48
49## Kernel Object and LK
50Some kernel objects wrap one or more LK-level constructs. For example the
51Thread object wraps one `thread_t`. However the Channel does not wrap
52any LK-level objects.
53
54## Kernel object lifetime
55Kernel objects are ref-counted. Most kernel objects are born during a syscall
56and are held alive at refcount = 1 by the handle which binds the handle value
57given as the output of the syscall. The handle object is held alive as long it
58is attached to a handle table. Handles are detached from the handle table
59closing them (for example via `sys_close()`) which decrements the refcount of
60the kernel object. Usually, when the last handle is closed the kernel object
61refcount will reach 0 which causes the destructor to be run.
62
63The refcount increases both when new handles (referring to the object) are
64created and when a direct pointer reference (by some kernel code) is acquired;
65therefore a kernel object lifetime might be longer than the lifetime of the
66process that created it.
67
68## Dispatchers
69A kernel object is implemented as a C++ class that derives from `Dispatcher`
70and that overrides the methods it implements. Thus, for example, the code
71of the Thread object is found in `ThreadDispatcher`. There is plenty of
72code that only cares about kernel objects in the generic sense, in that case
73the name you'll see is `fbl::RefPtr<Dispatcher>`.
74
75## Kernel Object security
76In principle, kernel objects do not have an intrinsic notion of security and
77do not do authorization checks; security rights are held by each handle. A
78single process can have two different handles to the same object with
79different rights.
80
81## See Also
82[Handles](handles.md)
83