1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
/**
* @mainpage RNT
*
* @image html logo.png
* <p><a href="https://www.gnu.org/licenses/agpl-3.0.html"><img src="https://www.gnu.org/graphics/agplv3-with-text-162x68.png" alt="GNU AGPLv3" /></a></p>
*
* RNT is an experimental database kernel inspired by the
* object-management model of the Windows NT kernel. The project applies
* explicit object management to database state: relations, tuples,
* transactions, namespaces, permissions, cursors, and handles are
* runtime-managed objects rather than isolated subsystems.
*
* @section motivation Motivation
*
* The NT kernel is a good model for a dedicated database kernel for three
* reasons.
*
* **The object manager.** NT's OB gives every kernel resource a named path,
* a security descriptor, and a uniform open/close lifecycle enforced through
* handles. A database kernel has the same requirements. Rather than building
* those mechanisms independently for each database concept, this project
* borrows the NT object manager's shape directly.
*
* **Physical backends as drivers.** NT device drivers expose a narrow
* dispatch table. The kernel routes I/O through it without knowing whether
* the device is a local disk or a network adapter. Storage backends here
* follow the same pattern. A remote backend like etcd is just another
* driver, but brings its own concerns: network latency, connection
* management, and the possibility of partial failure. The driver boundary
* keeps those concerns inside the backend module.
*
* **Clients as environment subsystems.** NT supports Win32, POSIX, and OS/2
* as environment subsystems layered above a common native API. A database
* client works the same way: a PostgreSQL wire adapter, a MySQL wire
* adapter, or an HTTP/JSON interface each translates its protocol into
* kernel-level operations. The kernel never sees SQL syntax or protocol
* framing.
*
* @section architecture Architecture
*
* - ObjectManager registers, locates, and references database objects by
* logical path.
* - PermissionsManager keeps capability checks separate from object lookup.
* - IdentityManager decides whether an object supports a requested lifecycle
* operation.
* - LifecycleManager models monitoring, pinning, cleanup, and contention.
* - HandlerManager orchestrates the full open/close workflow and owns handle
* allocation.
* - CursorManager provides a pull-based iterator over storage, abstracting
* pagination, snapshot pinning, and scan boundaries.
* - VM separates terminating first-order relational retrieval (Tarski) from
* higher-order logic execution (Karuta).
* - NamespaceReferenceManager handles logical path mapping and namespace
* isolation, including private branch shadowing and atomic multi-reference
* updates.
*
* @section building Building
*
* Requires the Nix development shell on GNU/Linux. The flake provides GCC,
* CMake, Ninja, SQLite, PicoSHA2 headers, Catch2, Doxygen, and Graphviz.
*
* @code{.sh}
* nix develop
* cmake --preset gnu-debug
* cmake --build out/build/gnu-debug
* @endcode
*
* A release build uses @c --preset @c gnu-release.
*
* @section docs Generating Documentation
*
* @code{.sh}
* doxygen Doxyfile
* @endcode
*
* Generated HTML is written to @c docs/generated/html.
*
* @section license License
*
* RNT is free software licensed under the GNU Affero General Public License
* v3.0. See the repository @c LICENSE file for the full terms.
*
* Copyright (C) 2026 Marcos Magueta, RNT contributors, and Don't Rely on
* Nulls. Maintainer: Marcos Magueta.
*/
/**
* @namespace nt
* @brief Contains the Relational NT runtime managers and API facade.
*/
|
