*: introduce paths for module contexts

There needs to be a way to address module context instances
by name externally, in a manner complementary to settings and
taps.

This commit adds a string-based path to til_module_context_t, and
modifies til_module_create_context() to accept a parent path
which is then concatenated with the name of the module to produce
the module instance's new path.

The name separator used in the paths is '/' just like filesystem
paths, but these paths have no relationship to filesystems or
files.

The root module context creation in rototiller's main simply
passes "" as the parent path, resulting in a "/" root as one
would expect.

There are some obvious complications introduced here however:

 - checkers in particular creates a context per cpu, simply using
   the same seed and setup to try make the contexts identical at
   the same ticks value.  With this commit I'm simply passing the
   incoming path as the parent for creating those contexts, but
   it's unclear to me if that will work OK.  With an eye towards
   taps deriving their parent path from the context path, I guess
   these taps would all get the same parent and hash to the same
   value despite being duplicated.  Maybe it Just Works, but one
   thing is clear - there won't be any way to address the per-cpu
   taps as-is.  Maybe that's desirable though, there's probably
   not much use in trying to control the taps at the CPU
   granularity.

 - when the recursive settings stuff lands, it should bring along
   the ability to explicitly name settings blocks.  Those names
   should override the module name in constructing the path.
   I've noted as such in the code.

 - these paths probably need to be hashed @ initialization time
   so there needs to be a hash function added to til, and a hash
   value accompanying the name in the module context.  It'd be
   dumb to keep recomputing the hash when these paths get used
   for hash table lookups multiple times per frame...

there's probably more I'm forgetting right now, but this seems
like a good first step.

fixup root path

0 files changed, 0 insertions, 0 deletions