Should frequency_mask_trigger_binding::do_dump_config include dumping the mask data, since those are configurable? The con being that it adds two arrays of 4096 floats each, which is messy (and may break dripline-python by producing payloads that are too big, if that's still a thing). The pro being that it is configurable, and this would make it easier to fully restore the FMT state. Another option would be to return the other params and also dump the FM and FM-data to some hard coded path (in /tmp?), there could even be a mask-configuration: /tmp/mask_dump.yaml entry in the dump to match.
There is subtlety. We had decided to use boost::filesystem::unique_path to write the mask file in /tmp whenever do_dump_config is called. After making f_mask_mutex mutable, and write_mask a const function, there is a runtime error resulting from do_dump_config being called prior to the node being fully configured. When this happens, the mask_configuration is set to the generated tmp yaml filename, which does not exist. The node seems to then try to configure itself against that file, resulting in a yaml error. I have not traced exactly where this is happening.
I believe we like the behavior I was attempting, but we will need to figure out where the logic needs to change to avoid this startup issue... Don't have time for now, so the mask configuration is being left out of the dumped config until we have more time to track it down. This issue serves to hold the outstanding pieces of #67, which should be closed asap.
An outstanding question from resolving #67
There is subtlety. We had decided to use boost::filesystem::unique_path to write the mask file in /tmp whenever do_dump_config is called. After making f_mask_mutex mutable, and write_mask a const function, there is a runtime error resulting from do_dump_config being called prior to the node being fully configured. When this happens, the mask_configuration is set to the generated tmp yaml filename, which does not exist. The node seems to then try to configure itself against that file, resulting in a yaml error. I have not traced exactly where this is happening.
I believe we like the behavior I was attempting, but we will need to figure out where the logic needs to change to avoid this startup issue... Don't have time for now, so the mask configuration is being left out of the dumped config until we have more time to track it down. This issue serves to hold the outstanding pieces of #67, which should be closed asap.