Thanks, Marc! I had not noticed how cleanly it is already partitioned. I think making the modes into dynamically loaded modules would be a very nice addition and not too difficult since it's already isolated to a single .a file and entry point.
I'm not so sure it needs to be part of the bof file. Since the bof file is typically (always?) built on x86 hardware, it seems like you'd either just be bundling a pre-built PPC library or needed to support cross compilation and linking. The former seems like not adding much value and the latter seems like way too much toolchain overhead. Perhaps a good compromise would to provide a way for the bof file to contain the name(s) of the mode(s) that should be loaded by tcpborphserver2 when the bof file is programmed. The loadable "mode modules" would be expected to be pre-built and living in the ROACH filesystem (possibly after having been uploaded through tcpborphserver2)? This tcpborphserver2 stuff is not at the top of my stack right now, but when it is I'll be happy to look into making the modes dynamically loadable. Thanks again, Dave On Oct 16, 2010, at 4:00 AM, Marc Welz wrote: >> 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 >
