Kernel Internal Modules and Better Module Ordering

[jnterry]

The logging and thread system can in fact be thought of as modules, with stuff to do for init, per tick, and shutdown.

It may be nice to have a way to load a module from pointer rather than from dynamic library and refactor this code to use a module based interface.

Note that we need better way or ordering module execution before this can be done, as the thread and log modules should be initialized first and tick first. Note that we may have issues such as graphics module should be initialized before game module, but game module should tick before graphics module. We need a better way of encoding the dependencies between modules as in the order in which they operate.

An alternative to encoding dependencies is just to allow each module to have a pretick, tick and post tick function - that should hopefully be sufficient for all use cases I've thought of so far

[jnterry]

As an example of a complex dependency ordering, consider:

Pretick:

• kernel internal pre-tick thread setup

On tick:

• game module handles input
• entity component system runs simulation

Post Tick:

• graphics module performs rendering
• log buffer is flushed

We probably want to load the graphics and ecs modules before the game module, so that game init can do some useful setup -> but game needs to run BEFORE these. Hence just having pretick, on-tick and posttick callbacks may not be sufficent.

ECS simultation could be in post-tick, but that feels a bit odd. We want pre, on and post the have semantic meanings (setup, simulation, response to sim/teardown), if we arbitrarily blur this its very hard to predict what will happen.

Maybe we do need more complex marking of dependencies. There is also a question of if a single module would ever want multiple tick callbacks, each of which occurs at different point during the tick?