questions about loading mods

[tve]

I have a couple of questions about loading mods dynamically on an esp32, meaning over the network by an app that is running on the board. What I'd like to do is receive a mod over the network and save it to flash, then perform a reset such that this mod gets loaded. I'm trying to understand what is required to do that safely currently, and perhaps how it could be made more flexible. Questions:

1. I believe that before installing a new mod into flash a reset is required to ensure that no code/data from the old mod is in-use in any VM? And it appears that if one zeroes the first 16 bytes of the flash area this prevents the mod from being recognized & loaded after the reset?
2. After the mod is installed in flash it appears that only a reset can load it, there is no call to tell the VM to load it now? I.e. in total two resets are required, one before installing the mod and one after?

Looking at future options:

1. I gather that if the mod is in-use there is no safe way to "unload it" and overwrite the flash area because some code or data of the mod could be in-use somewhere in a VM? This means that either a reset prior to installing is required or an A/B two-partition scheme is required?
2. The main annoyance of a reset is the loss of connectivity, which can easily take 10-15 seconds to re-establish in the case of Wifi. Is there any existing machinery to perform a "soft-reset", e.g. stop all VMs and start the default VM from scratch? With some fiddling this could be done while keeping Wifi connected...
3. Can a mod be loaded, i.e. fxMapArchive be called after the VM is already running or does it have to happen right at creation time?
4. If I wanted to load two mods, would it "simply" be a matter of calling fxMapArchive twice, as is done in xsHost.c:modInstallMods? I'm not clear about the role of kModulesStart and wonder whether the memory mapping would result in a conflict.

[phoddie]

That's a lot of questions. I won't try answering all of them completely at once.

I believe that before installing a new mod into flash a reset is required to ensure that no code/data from the old mod is in-use in any VM? And it appears that if one zeroes the first 16 bytes of the flash area this prevents the mod from being recognized & loaded after the reset?

Correct.

After the mod is installed in flash it appears that only a reset can load it, there is no call to tell the VM to load it now? I.e. in total two resets are required, one before installing the mod and one after?

The default mod loader needs to run early because of symbol mapping.

I gather that if the mod is in-use there is no safe way to "unload it" and overwrite the flash area because some code or data of the mod could be in-use somewhere in a VM? This means that either a reset prior to installing is required or an A/B two-partition scheme is required?

Correct. If the mod is in-use, overwriting it is problematic since that would alter its bytecode and strings.

FWIW – in a project where flash was tight, instead of an A/B scheme, we have just a single mod partition. When an update is available, we invalidate the current mod, restart, download the mod over the previous one, and then restart. It is basically invisible to the user.

The main annoyance of a reset is the loss of connectivity, which can easily take 10-15 seconds to re-establish in the case of Wifi. Is there any existing machinery to perform a "soft-reset", e.g. stop all VMs and start the default VM from scratch? With some fiddling this could be done while keeping Wifi connected...

The mctest tool -- what we use to run unit tests -- enables an obscure feature (see MODDEF_XS_TEST) that allows it to kill and relaunch the main VM without a restart of the MCU. We use the to be able to run tests back-to-back quickly (each test needs to run a fresh VM). It also has the side-effect you describe: keeping the Wi-Fi connection active across tests.

Finally, as I may have mentioned previously, XS has provisions for other mod loaders. We use that in some private projects but haven't yet published. It supports multiple mods active simultaneously, loading mods at any time, and running mods from RAM. It works by building on the Compartment module loader in Hardened JavaScript. It works well, but you won't like it because it isn't well documented yet. ;)

[phoddie]

That's a little hardware-ish sounding and also kind of overlaps with "virtual machine", both of which could be confusing. We already have device -- I'm not sure we can easily explain when to use device versus machine?

[tve]

device broke down for me when I started seeing all the device.network.* stuff...
I believe System is pretty good. Another option I can come up with is Power or LowPower: that could include functions to control power states, deep sleep, etc, and reset/shutdown are not a huge stretch from there... Yet another name might be Processor. Processor.reset, Processor.softReset, Processor.deepSleep, Processor.clockRate, ... seem to work pretty well.

[phoddie]

I prefer Processor to Power. Processor might not scale well to multi-core silicon (not so rare these days) though. I'm thinking of cases where a setting might apply to one core but not another. Maybe I'm over thinking it though.

All that kind of thing varies quite a bit by silicon and RTOS. An alternative could be just to have an "ESP32" object that provides these things in a way that makes sense for ESP32 family. That sidesteps the issue of trying to find APIs that work across silicon vendors and then explaining how they map to the underlying silicon. Or that could hang off Processor as in Processor.ESP32 so that common things (restart, at least) are consistent across silicon and vendor specific things are explicitly accessed as such.

[tve]

Processor sounds really good to me. Processor.ESP32 for family-specific stuff also. For multicore I don't see a problem in passing the core number/designator to relevant functions (could be optional/defaulted param), but I suspect that's going to be silicon specific almost regardless.

[phoddie]

For multicore I don't see a problem in passing the core number/designator to relevant functions (could be optional/defaulted param), but I suspect that's going to be silicon specific almost regardless.

Sure.