Plans

[Ivan-Velickovic]

It has been about 6 months since I initially released the tooling and have been using it internally at TS.

Currently the tooling works fine for systems that are made up of simple components connected to various sDDF sub-systems. However, it does not scale well and lacks introspection for systems that require more flexibility such as the example LionsOS firewall system.

There are a number of larger issues we need to solve before we start advertising it and stop calling it 'experimental'. This issue aims to track this work.

Below is a list of the main things we want to have to improve the tooling:

• Rename it to something better, sdfgen is too close to 'sDDF'
• Rewrite it in Python
  • I initially wrote all this code in Zig because it was easier for me and I was experimenting with the language. It looks like that choice is no longer correct as there are various people at TS that need to touch this code on a regular basis and it doesn't make sense for them to have to learn a new language to deal with this.
• Put each project-specific code in its respective repo (LionsOS abstractions in the LionsOS repo, sDDF abstractions in the sDDF repo, etc).
  • This was always the plan, but really should be done soon.
• Try a more declarative approach with sDDF components by having the structs/classes declare what connections they require etc. Not sure about this yet but see how it goes.
• objcopys in the build system need to go.
  • Either the tooling calls objcopy itself or we go with having Microkit memory regions filled with the contents of a file with the serialised data of the configuration structs.
• Make sDDF configuration structs less error-prone by actually looking at the definition and seeing if it corresponds to the tool's definition of it. Either look at libclang for parsing the struct directly or DWARF debug info for this.
• Make the infrastructure that exists for doing config struct stuff accessible by the user so that when we build more complex systems like the firewall the user (e.g the system developer) they can use it for their own custom purposes.

Most of these changes are internal, but should allow making more complex systems a lot easier and make it easier to change the tooling itself.

[omeh-a]

Put each project-specific code in its respective repo (LionsOS abstractions in the LionsOS repo, sDDF abstractions in the sDDF repo, etc).

On this: I think there is possibly more to discuss just on merit of Python's terrible import system. I think with the sDDF it will be OK, but I think telling the metaprogram to find the deps with more levels like LionsOS could get a bit funky. Making distant imports work in a platform agnostic way is a lot trickier than it seems. I don't have a better suggestion RN though

[Ivan-Velickovic]

Making distant imports work in a platform agnostic way is a lot trickier than it seems

I don't understand, there is nothing platform specific here.

[Ivan-Velickovic]

We also already pass the path to sDDF to the metaprogram anyways (but I agree, it's not great. However I think it's better than having everything in one repo)