> Hi, Jason, > > Looking at the recent commit activity for tcpborphserver2, it seems like a > lot of instrument-specific functionality is being added, which moves it away > from being a general purpose "BORPH over TCP/IP" utility. If everybody adds > their own instrument-specific functionality to tcpborphserver2, it will > become quite bloated and confusing. Do you guys have any plans to support > loadable modules to allow users to load design-specific functionality > dynamically into tcpborphserver2 (e.g. upon programming a new bitstream into > the FPGA)?
We are kind of halfway there: Instrument specific logic is confined to separate modes, the code for each mode is in its own directory, and tcpborphserver2 can be built without particular modes. See the toplevel Makefile - though I assume you have noticed this. Notice that the logic for each mode is built as a .a file and loaded at a single entry point. I hope I have made tcpborphserver2 sufficiently modular so that one separate this a bit more - so with not that much work it should be possible for tcpborphserver to dlopen the .so for a particular mode, which had previously been a .a file. It would require some changes to the .bof file format, but it should be possible to have a .bof file contain the .so, so that this could then be loaded on demand. If you are interested in implementing this logic, let me know and I can give to some pointers - for the time being I am working on the control logic for our instruments and so don't have that much time to spare. regards marc
