mirror of
https://github.com/20kdc/OC-KittenOS.git
synced 2024-11-23 19:08:05 +11:00
e984f97ea9
Basically, need to finish the User Libraries and User Space sections. The entirety of kernel space should be documented now at least.
93 lines
2.5 KiB
Plaintext
93 lines
2.5 KiB
Plaintext
The KittenOS NEO Kernel,
|
|
aka "init.lua", or as I like to call
|
|
it, "KNOSKRNL", is what happens when
|
|
someone tries to write a microkernel
|
|
in Lua, and make it efficient.
|
|
|
|
Obviously, the result is not entirely
|
|
what would be expected from a kernel
|
|
at all, nevermind a microkernel.
|
|
|
|
In particular, it borrows an
|
|
important concept, specifically fast
|
|
yet secure IPC.
|
|
|
|
By which I of course mean that the
|
|
IPC consists of programs giving Lua
|
|
values to each other directly, and
|
|
the kernel giving the programs some
|
|
mechanisms to help secure this.
|
|
|
|
Not what you expected, I assume.
|
|
|
|
The "kn-" group of documents is about
|
|
the KittenOS NEO kernel.
|
|
|
|
This is specifically ONLY about the
|
|
kernel, and only about features the
|
|
kernel provides directly.
|
|
|
|
As the kernel provides many things to
|
|
everything under it, I believe this
|
|
is of great use.
|
|
|
|
It's now time for the notes about the
|
|
kernel side of the boot process.
|
|
|
|
Firstly, the startup of sys-init is
|
|
unlike any other - specifically, it
|
|
has a nil callerPid/callerPkg pair.
|
|
|
|
This is because no application ran a
|
|
function to create the process - it
|
|
was created by the kernel.
|
|
|
|
Secondly, here's what goes on in the
|
|
kernel when an Access is registered,
|
|
and when it's accessed:
|
|
|
|
1. The service requests access with
|
|
an AID starting with "r.".
|
|
2. The security policy presumably
|
|
accepts the registration.
|
|
3. A blank registration in the table
|
|
"accesses" is made immediately.
|
|
This registration always fails to
|
|
be retrieved, but exists.
|
|
4. A function is returned to reset
|
|
the registration.
|
|
5. The service calls the function,
|
|
thus the registration is now
|
|
completed.
|
|
|
|
6. The user-process requests access
|
|
with an AID starting with "x.",
|
|
everything after matching that
|
|
in the "r." registration.
|
|
7. The security policy presumably
|
|
accepts the use of that API.
|
|
8. The callback in the registration
|
|
is called.
|
|
It's first return value is sent
|
|
back to the user-process.
|
|
If it errors, then nil is given
|
|
instead (the error is not sent).
|
|
|
|
Thirdly, the security policy is set
|
|
by getting the kernel global table
|
|
with "k.root", and then changing the
|
|
global "securityPolicy".
|
|
|
|
Given this operation is only ever
|
|
performed once in typical use, and
|
|
having control over it is equivalent
|
|
to instant root, it seems fitting
|
|
that it is done this way.
|
|
|
|
(Making absolute power absolute is
|
|
also why the kernel loves globals.)
|
|
|
|
Finally, the kernel prevents those
|
|
processes that aren't "sys-" from
|
|
calling "sys-" processes.
|