Code review comment for lp:~epics-core/epics-base/link-support-2

Yes, the JSON_LINK type is intended for something like asynDriver that wants flexibility. The IOC may not know until iocInit or even runtime how to parse the complete hardware address, but the device layer can work it out.

I had forgotten exactly what you were working on, so your responses are helpful. I don't really like your lset hijacking approach, I'm trying to see if I can provide an alternative that will put both pva and ca link types at the same level, but I'm not there yet.

I'm currently adding an LSET routine for putCallback as required by the dev*oSoftCallback device supports — actually it implements put-wait-reprocess since the only thing the callbacks are ever used for is to reprocess the record containing the link after the put has completed. Currently these device supports only work over CA, but I see no real reason they can't be extended to support dbNotify (i.e. local DB) links as well, that's JMOP.

I also want to add a dbLinkIsRemote() routine which is really what many of the remaining tests for (plink->type == CA_LINK) are really asking about; that should allow all the CA-specific calls in the calcout record type to use the generic API as well. A remote link type is one that can connect or disconnect asynchronously, so both ca and pva are remote; I want to remove as much code that looks at the plink->type value as possible.

For fully generic link types we will need one or more routines that get integrated into the JSON parser used for link-resolution and either accept or reject the link address. I'm not sure yet if these should be included in the LSET or in some other table (the one that the DBD link entry actually refers to); I'm leaning towards the latter for simplicity's sake, but haven't implemented anything yet.