Repository navigation
Starting an IOC without QSRV #185
Description
Could we have a way to start a soft IOC up, without QSRV? I believe we'd need to remove the following lines from __init__.py:
dbLoadDatabase('pvxsIoc.dbd', pvxslibs.path.dbd_path, None)
ctypes.CDLL(find_dso('pvxslibs.lib.pvxsIoc'), ctypes.RTLD_GLOBAL)
os.environ.setdefault('PVXS_QSRV_ENABLE', 'YES')to achieve this.
Activity
AlexanderWells-diamond commentedon Mar 25, 2025
Is it not sufficient to set the
PVXS_QSRV_ENABLEenvironment variable toNO? A quick test on my end seems to show that disabling the PVXS QSRV library loading. Or do you require a programmatic way to do this upon module import?coretl commentedon Mar 25, 2025
Does that stop it serving over PVA though? I thought it would then use the older pvAccess libraries that are already loaded?
AlexanderWells-diamond commentedon Mar 25, 2025
From testing it appears to still serve over PVA -
pvgeton a PV works whether the environment variable is set toYESorNO.Discussing this with @coretl, we believe what is happening is that the PVAccess server is always being initialized upon loading of the library. The environment variable controls the older PVAccess library's initialization. What is requested is for a way to disable this completely.
The simplest way to achieve this would be to re-use that environment variable, and check its value before loading the DBD and DSO. If it is
YESthen we proceed with the loading.This is not ideal as it then means the configuration is happening at import time, which often leads to having to delay imports, which is not an ideal situation. A more useful way to do this would be as an option to iocInit(), or some other configuration function call before the IOC starts, but I don't currently know enough about the system to know if this is possible or not.
AlexanderWells-diamond commentedon Mar 27, 2025
@coretl @shihab-dls I've got an initial implementation in PR #186. Could I ask you to test that this fixes your issue/suits your needs?
Could I also ask for a few words explaining why exactly you want this? From my understanding it's because you want to run pythonSoftIOC for Channel Access, and p4p for PVAccess?
coretl commentedon Mar 27, 2025
That is correct, for
FastCSwe would like to use pythonSoftIOC for CA support, but p4p for PVA support, to support CA and PVA at the same time. This is because p4p will allow us to make more expressive structures (like enums with more entries) than we get with QSRV, so we want to give those to PVA clients, while still falling back to the less expressive structures for CA clients (like the archiver temporarily)shihab-dls commentedon Mar 28, 2025
Thank you! As @coretl has mentioned, this helps us exclusively serve
pvaviaP4P, so I believe #186 meets our needs.