Starting an IOC without QSRV

[shihab-dls]

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.

[AlexanderWells-diamond]

Is it not sufficient to set the PVXS_QSRV_ENABLE environment variable to NO? 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]

Does that stop it serving over PVA though? I thought it would then use the older pvAccess libraries that are already loaded?

[AlexanderWells-diamond]

From testing it appears to still serve over PVA - pvget on a PV works whether the environment variable is set to YES or NO.

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 YES then 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]

@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]

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?

That is correct, for FastCS we 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]

@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?

Thank you! As @coretl has mentioned, this helps us exclusively serve pva via P4P, so I believe #186 meets our needs.