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