Ad-hoc TFTP server driver

[flxzt]

It would be nice to be able to start a tftp server in an ad-hoc way on a remote machine through a driver when it is needed in addition to the current TFTPProvider <-> TFTPProviderDriver resource/driver pair which requires an existing deployment.

This would make the delopyment of the infastructure easier and allows for more flexibility and robustness when for example booting over TFTP in a strategy. Then it could be ensured that for example the path of the TFTP server always matches the uboot tftp string.

[jluebbe]

This is (currently) by design, as it naturally allows using one TFTP (/HTTP/NFS) server for multiple places. When starting per Resource, we'd need to allocate ports per instance, which also complicates usage on the target. I'm skeptical it worth that complexity just to avoid a per-exporter TFTP service.

[flxzt]

I understand the reservations about adding too much complexity to the framework from the perspective of maintainability.

Only as a note from my perspective as a user: what I had in mind: couldn't there be a {TFTP/HTTP/NFS}ServerManager that allocates unique ports and gives them back as part of the driver API? Then the user could retrieve the port to construct for example u-boot tftp boot commands.
Similar to how SyncedFile gives back the path for the created file instead of "being told" the path, ensuring avoiding collisions

The reason why I am suggesting this is: because in one of my test setups the DUT can't be booted directly from the exporter, it only can communicate with a second device. A driver that starts an ad-hoc TFTP server on a remote system could be used a lot easier to use than a "proper" tftpd deployment. The only requirement would then be that the ftfpd binary is present on this second device